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completed manually using standardized procedures and controls to ensure responsiveness 
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and recording information as it pertains to the Air Tasking Order within the Direct Air 
Support Center. A relational database design is proposed using Entity-Relationship 
modeling. A simple prototype of the system is implemented in dBASE IV to demonstrate 
proof of concept. The major benefit of the database approach is that databases are 
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I. INTRODUCTION 


A. BACKGROUND 

Information has always been the most important resource in command and control 
decisions. Unfortunately, communicatıon has been viewed as a distant relative of the 
military profession. It is only in the last couple of decades that information systems to 
support the command, control and communication processes have been recognized in their 
own right by the military. Technological advances in the development of digital 
techniques for the representation and processing of information, and microelectronics have 
led to the fulfillment of long existing information requirements. Automated 
communications and information systems have enabled decision makers to cope 
effectively with the complexity of command and control on the battlefield. 

The Marine Air Command and Control System (MACCS) execution of Direct Air 
Support is based on the concept of centralized command and decentralized control. It is 
completed manually using standardized procedures and controls to ensure responsiveness 
in a highly dynamic situation. Based on the information contained in the Draft 
Operational Requirements Document (ORD) for the Direct Air Support Central, Marine 
Corps Combat Development Command identified operational deficiencies in the data 
processing capabilities of the Direct Air Support Center (DASC). The DASC requires an 


automated message and information handling capability to exchange, store, display, and 


manipulate digital information using established Marine Tactical Systems and Message 
Text Format (MTS/MTF) standards. 

This thesis investigates the issues in developing and implementing a database 
processing system for receiving, processing, disseminating, and recording information 
required by the DASC as it pertains to the Air Tasking Order (ATO). Background of the 
MACCS, DASC functions, the ATO cycle, and lessons learned from Operation Desert 
Storm are discussed. Application of an integrated Database Management System (DBMS) 
within the DASC will be explored addressing system and joint inter-operability 
requirements/problems. Man-machine interface will be stressed in the DBMS. The 
potential use of this system will be researched to improve the efficiency and effectiveness 
of information flow and decision making within the DASC, the MACCS, and the Fire 


Support Coordination Center (FSCC). 


B. SCOPE 

The focus of this thesis is a system requirements review of an integrated DBMS for 
the receiving, processing, disseminating, and recording of the ATO in the DASC. 
Research is specifically intended to model a system that uses available data in 
standardized format to build a database, query the database, and then utilize the 
information to: (1) provide information to decision makers, (2) disseminate information 
to those who require it, (3) add and subtract information within the database. Research 
will cover database architecture in an integrated DBMS to include consideration in man- 


machine interface. 


C. THESIS OBJECTIVES 
The primary objective of the thesis is to identify the system and information 
requirements for a database processing application that automates the ATO functions 


within the DASC. This will entail the following steps: 


1. Determine the feasibility of automating the ATO functions within the DASC. 


2. Demonstrate the potential to improve information flow and decision making within 
the DASC. 


3. Highlight problem areas in developing and implementing a DBMS for use in the 
DASC. 


4. Translate the user defined data requirements into a conceptual model, and design 
and build a database using that model. 


D. RESEARCH QUESTIONS 

There are several approaches to implement a database processing application. The 
primary research question is to determine the information requirements for a database 
application and generate a database design that fulfills the determined requirements. In 
support of the primary question, the thesis will identify the system requirements of an 
automated database and the design issues to be addressed in modeling the proposed 


system. 


E. LITERATURE REVIEW AND METHODOLOGY 
Background knowledge on the subject area was obtained through research into 
technical reports, academic publications, and a course on relational databases. The 


doctrinal and operational knowledge was gained from doctrinal publications, technical 


reports, DASC project documentation, and interviews with Marines in the air support 
control community. 
The methodology used in this thesis generally follows the application development 


process outlined by Kroenke and Dolan (1988, p. 75-82) which consists of five phases: 


1. The definition phase attempts to define the scope of the project. 


2. The requirements phase determines as specifically as possible what the new 
system must do. 


3. The evaluation phase studies alternative solutions to the requirements. 
4. The design phase involves creating the logical structure of the database. 


5. The implementation phase constructs the system according to the design. 


The scope of this thesis, as defined earlier, will look at the user requirements of a 
database processing system and model a database based on those requirements. The 
thesis will emphasize the design phase of the database based upon user defined 
requirements. Alternative database models will be addressed, and implementation of the 


design will be demonstrated on a specific microcomputer DBMS. 


F. SUMMARY OF FINDINGS 

The intent of relational database design is to increase the accessibility of database 
information to all users, minimize redundancy, and allow for implementation of future 
applications to the DBMS. DBMS capabilities include mechanisms for displaying data 
through report generators and responding to "ad hoc" database queries. The relational 


model allows data independence, meaning that applications maintain more flexibility for 


changes in the future than traditional file processing approaches. The database design 


developed by the entity-relationship approach is independent of and not restricted by the 


capabilities of any specific database system. It can be implemented in any relational 


DBMS environment. These concepts are important in the rapidly changing command and 


control environment. As users see how automation benefit decision making, their "need" 


for additional data and information processing will grow. 


G. 


ORGANIZATION OF THE STUDY 
The remainder of the thesis is organized as follows: 


Chapter II provides the background to the MACCS to include the DASC functions 
and the ATO process. It lays the groundwork for demonstrating how a DBMS 
could improve the efficiency and effectiveness of decision making and information 
flow within the DASC. 


Chapter III explores the technology, man-machine interface, and system 
requirements of an automated information system, and identifies the information 


flow requirements within the DASC. 


Chapter IV explores database processing concepts to include design, tools, and 
techniques. 


Chapter V presents a database design and implementation for the DASC application. 


Chapter VI summarizes the benefits of a database processing approach for the 
DASC application. 


DU MARINE AIR COMMAND AND CONTROL OPERATIONS 


A. GENERAL 

This chapter presents the fundamentals of control of aircraft and missiles, the 
MACCS, the DASC, the ATO cycle, and lessons learned from Operation Desert 
Storm/Shield. The objective is to document the existing MACCS operational environment 
and eventually to identify the information flow requirements of the DASC with respect 
to the ATO. These requirements will be specified in Chapter IH and serve as the basis 


for constructing a database application based on the model discussed in Chapter IV. 


B. CONTROL OF AIRCRAFT AND MISSILES 

The capability to conduct successful tactical air operations is essential to the 
execution of military operations. The Marine Corps has organized an aviation combat 
arms capable of meeting the requirements of a flexible, responsive aviation combat 
element specifically tailored to meet the anticipated tactical situation. When combined 
with the requisite ground elements, the result is a balanced, self-sufficient, cohesive 
organization composed of air and ground arms known as the Marine Air-Ground Task 
Force (MAGTF). 

A task organized Aviation Combat Element (ACE) will normally be formed to fully 
support the MAGTF. The ACE supports the MAGTF with firepower and mobility it 


would not have otherwise. The ACE is not a permanent organization, but is organized 


and equipped to provide the aviation functions required to accomplish the assigned 
mission. The tasks required to support the ACE’s mission fall into six functional 
categories: offensive air support, anti-air warfare, assault support, air reconnaissance, 
electronic warfare, and control of aircraft and missiles. 

Control of aircraft and missiles is defined as “the coordinated employment of 
facilities, equipment, communications, procedures, and personnel which allow the 
MAGTF commander to plan, direct, and control the efforts of the ACE to support the 
accomplishment of the MAGTF’s mission." (FMFM 5-60, 1990, p. 1-1-2) According to 
JCS Pub 1, command and control is "the exercise of authority and direction by a properly 
designated commander over assigned forces in the accomplishment of his mission." (JCS 
Pub 1, 1 April 1989, p. 76) Command includes ”...the authority and responsibility for 
effectively employing available resources...for the accomplishment of assigned missions." 
(JCS Pub 1, 1 April 1989, p. 76) Control is defined as the "authority which may be less 
than full exercised by a commander over part of the activities of subordinate or other 
organizations.” (JCS Pub 1, 1 April 1989, p. 87) Therefore "control of aircraft and 


missiles’ is synonymous with "authority over aircraft and missiles." 


C. MARINE AIR COMMAND AND CONTROL SYSTEM 

The ACE commander exercises operational control over his assigned forces through 
the MACCS. The MACCS is an integral part of the ACE’s organizational structure and 
consists of units specifically equipped with personnel, facilities, communications, and 


trained in procedures to support the command and control of all MAGTF air operations. 


The MACCS operates under the principle of centralized command and decentralized 
control for maximum responsiveness to combat operations. 

The personnel and equipment required to establish the MACCS are contained 
primarily in the Marine Air Control Group (MACG) and its subordinate squadrons. The 
functional components (personnel and equipment) of the MACCS depicted in Figure 1 
include: 


e Tactical Air Command Center (TACC) is the senior MAGTF air command and 
control agency which serves as the operational command post of the tactical air 
commander (TAC), usually the ACE commander. The TAC and his staff execute 
the current air battle and plan for the future battle culminating in the publication of 
the Air Tasking Order (ATO) and appropriate fragmentation (FRAG) orders. 


- Sector Antiair Warfare Coordinator’s (SAAWC’s) facility, which is normally 
colocated with the Tactical Air Operations Center (TAOC), is the senior air defense 
battle manager for the ACE. It provides the interface between the TAOC and 
TACC. 


- TAOC and Early Waming/Control (EW/C) sites detect, identify, and control the 
intercept of hostile aircraft and missiles. 


- Direct Air Support Center (DASC) processes immediate air support requests, 
coordinates aircraft employment with other supporting arms, and controls aircraft 
transmitting its area of responsibility. A complete description of the DASC’s roles, 
tasks, inter-agency relationships and information needs will be discussed later. 


- Air Support Radar Team (ASRT) provides day/night all-weather control of aircraft 
operating in support of MAGTF operations. 


- Subordinate Command Posts (CPs)/Combat Operation Centers (COCs) provide the 
primary control agency from which Light Antiaircraft Missile (LAAM) and Low- 
altitude Air Defense (LAAD) Battalions can direct and control the HAWK and 
Stinger missile systems. 


- Marine Air Traffic Control Squadron (MATCS) Detachment provide continuous all- 
weather air traffic services for expeditionary airfields and remote landing sites. 


- Airborne Control Agencies offer flexibility to operate either as an extension of the 
means of control to functional control agencies (Tactical Air Coordinator (Airbome) 
(TAC(A)), Helicopter Coordinator (Airborne) (HC(A))), in support of specific 
ground units (Forward Air Controller (Airborne) (FAC(A))), or in coordination of 
other aircraft (Refueling Area Coordinator (RAC)). 


e Tactical Air Control Parties (TACPs) are organic to the Ground Combat Element 
and provide air liaison to land forces and terminal control of aircraft. 


MACCS agencies have no control over aircraft or other units unless specifically 
delegated to them by the appropriate commander. Types of control that are usually 
delegated include: 

- Command. The TACC is the one MACCS agency that exercises command. 
- Air Direction. The authority to regulate the employment of air assets. 

- Air Control. The authority to direct the physical maneuver of air assets. 

- Airspace Control. The coordination, integration and regulation of airspace. 


- Terminal Control. A subset of control that applies to the delivery of ordnance, 
cargo, or personnel by aircraft. 


The MACCS will be tasked-organized to provide MAGTF commanders with the 
assets required for effective command, coordination, and control of all MAGTF air 
operations. Interagency relationships between the MACCS elements can be defined as 
the type of control each agency exercises. Development of the ATO is a form of air 
direction that the ACE commander exercises through the TACC. Air control can be 
thought of as an instruction given to a pilot by a control agency to alter his course. 
Airspace control is the authority to direct aircraft so the best use 1s made of a defined 
area of responsibility. The DASC exercises both air control and airspace control when 


authority has been delegated to them. The DASC will receive air direction via the ATO 
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Figure 1. MACCS Agencies and Control Authority 


from the TACC. Figure 1 depicts the MACCS and its control relationships with the 


various agencies. 


D. DIRECT AIR SUPPORT CENTER 
J. Background 
The Direct Air Support Center is the principle air control agency responsible 
for the direction of air operations directly supporting ground forces. The DASC processes 


direct air support requests, controls aircraft in its area of responsibility, manages terminal 
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control agencies in support of the ground combat element (GCE), and coordinates air 
missions requiring integration with other supporting arms. 

The DASC functions in a decentralized mode of operation under the command 
ofthe TACC. It is normally the first major air control agency ashore and normally lands 
with the senior Fire Support Coordination Center (FSCC) during scheduled or on-call 
waves. It physically or electronically colocates with the senior FSCC and works closely 
with this agency to ensure the coordination of air support with other supporting arms. 
The DASC maintains the capability to operate during mobile combat situations by 
displacing by echelon to preserve operational continuity. The "echelon DASC" will have 
the capability to perform the same tasks as the main DASC. 

Functional positions within the DASC include directors and net operators. 
Directors interface with, and control aircraft. Net operator coordinate with agencies 
extemal to the DASC. The functions and tasks performed by the directors and net 


operators within the DASC is discussed next. 


2. Tasks 
The DASC provides direct air support functions for the MAGTF by performing 
the following tasks: 


- To receive fragmentary operation orders (FRAGQOs) and ATOs from the TACC and 
coordinate preplanned scheduled direct air support. The ATO and FRAGOs are 
normally received on a daily basis but may be modified as changes occur. 
Information about these changes will normally come via the TACC. 


e To receive, process, and coordinates requests for immediate or on-call air support. 
These requests will normally originate from the supported ground combat element 
requesting tactical air, assault support, or medical evacuation. This is one of the 
most critical tasks performed by the DASC. 


l1 


To adjust preplanned scheduled aircraft and divert airborne assets based upon 
mission priority in coordination with the senior FSCC when delegated authority by 
the TAC. 


To provide coordination in the execution of direct air support missions with other 
supporting arms through the appropriate FSCC. 


To coordinate subordinate terminal control agencies as required. 


To receive and disseminate pertinent tactical information reported by aircraft 
performing direct air support missions. 


To provide aircraft and other air control agencies with advisory information for the 
safe conduct of flight. 


To monitor, record, and display information on direct air support missions. 


To maintain friendly and enemy ground situation displays, as necessary, to 
coordinate direct air support missions. 


To provide information to other MACCS agencies concerning the friendly and 
enemy situation to include aircraft position. 


To refer unresolved conflicts in supporting arms to the fire support coordinator and 


provide an operational point of contact to ensure air support is responsive to the 
tactical situation. 


3. Communication Links 


In order for the DASC to perform these tasks, rapid and reliable 


communication links must be maintained with agencies external to the DASC. The 


command and control connectivity between the DASC, the aircraft and these external 


agencies is accomplished by radio. The primary DASC interagency relationships depicted 


in Figure 2 include: 


DASC/TACC. The DASC is subordinate to the TACC and provides for 
decentralized control of direct air support missions including close air support 
(CAS), and assault support. The TAC will ideally delegate divert and on-call 
launch authority of aircraft to the DASC to ensure minimum response times to 
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MAGTF requirements. The TACC provides the DASC with appropriate ATOs, 
FRAGOs, aircraft call-signs, and aircraft availability. The DASC and the TACC 
exchange tactical information, intelligence, and the progress and effectiveness of 
direct air support missions. 


- DASC/FSCC. Since the FSCC is the final arbitrator for all supporting arm conflicts 
the DASC and FSCC maintain close ties. The DASC and FSCC must be able to 
exchange timely information on tactical information (fire support coordination 
measures, friendly/ enemy unit positions, etc.), pertinent — data, status of 


launch ae and other a data items. 
- DASC/Antiair Warfare (AAW) Agencies. The DASC must be able to exchange 
tactical data information and pertinent friendly aircraft location with the appropriate 


AAW agencies (TAOC, LAAD/LAAM CPs). 


- DASC/Airborne Controllers. The DASC must coordinate and exchange information 
with airborne control agencies pertaining to their responsibilities. 
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- DASC/ASRT. The ASRT is a terminal control agency subordinate to the DASC 
and receives all tactical data information from the DASC. 


- DASC/TACPs. The DASC receives and processes immediate air support requests 
from the terminal controllers (Forward Air Controllers (FACs)) and apprises the 
TACPs and FACs of their status. 

- DASC/OTHERS. The DASC will establish and maintain communication links with 
other agencies as required. Examples of this include, MATCS, Remotely Piloted 


Vehicle (RPV) Receiving Station, and the Air Force Air Support Operations Center 
(ASOC). 


4. Current Operations 

The DASC is a flexible, communications intensive facility that may be 
configured to support a variety of tactical situations. It is presently a manual system 
using procedural control methods and voice communication to fulfill its tasks. 

The ATO is issued by the TACC and distributed to the MACCS elements on 
a daily basis. This ATO may or may not be a re-creation of the Air Force ATO. The 
means of distribution of the ATO may be via message traffic through a message center, 
courier, or local area network. Considerable time is then expended in processing and 
disseminating the ATO data within the DASC and retransmitting applicable ATO mission 
data to the ASRT or TACP’s. The DASC receives voice or message traffic whenever a 
change to the ATO occurs. 

Requests for immediate air support are transmitted from the TACPs to the 
DASC over the voice only Tactical Air Request (TAR) Net. All FSCCs monitor the TAR 
net and may disapprove, or by their silence, give consent to, the immediate air request 
(Figure 3). Upon receipt, the DASC will concurrently process the request, and coordinate 


mission planning with the colocated FSCC. The DASC will fulfill the request by 
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diverting lower priority airbome aircraft or by launching on-call missions. Each request 
requires manual completion of a specific form, must be posted on display boards, and 
transmitted to the TACC. Upon completion of the request, mission data is manually 
recorded on the form and disseminated to the TACC and FSCC. 

As all types of operational message traffic increases, the DASC’s operational 
mission data becomes less current because of the workload in manual processing, 


dissemination, transmission and posting of information. 





E. AIR TASKING ORDER 
The ATO planning process for tactical air operations is a continuous activity that 


begins at the senior MAGTF level for the Marine Corps or the joint force theater level 
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in combined operations. The planning steps will be treated generically, using the Marine 
Corps as an example (Figure 4). The time sequence, usually 36 hours for the Marine 
Corps, would be longer when considering the joint level. The planning sequence provides 
background on how the ATO is generated and transmitted by the TACC and received and 
processed by the DASC. 

The MAGTF commander develops the strategy and establishes the objectives for 
the conduct of military operations and apportions the available force to the various air 
tasks for a specific period of time. Apportionment is usually expressed as a percentage 
of total available assets assigned to the various missions (CAS, AAW, etc.) or in terms 
of priority by mission or geographic area. This apportionment guidance is based on the 
recommendation from his component commanders (ACE, GCE, etc.) and is promulgated 
in the apportionment guidance. 

The ACE commander reviews his assets and allocates them in terms of sorties 
according to actual number of aircraft by type for each mission category consistent with 
the apportionment guidance. The future battle cell (FBC) in the TACC is responsible for 
developing the detailed plans of the ATO based on the apportionment and allocation of 
resources. The ground combat element provides the FBC with a prioritized target list for 
air interdiction targets and any additional preplanned requests to include a needed 
preplanned/immediate missions mix. The FBC considers the weather, enemy threat, 
availability of assigned forces and weapons, and target selection when developing the 


plan. Sorties in excess of MAGTF direct support requirements will be provided to the 
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Joint Force Commander for joint force tasking. The results of this planning process are 
disseminated as the ATO. 

Although there is no specific format for the ATO, the ATO provides the mission 
details, special instructions, general information and remarks required by the subordinate 
units to execute their assigned tasks. The ATO will normally be transmitted in message 
text format (USMTF) or marine tactical standard (MTS). The USMTF ATO message is 
further discussed Chapter II and is listed in Appendix C. 

Upon receipt of the ATO, aircraft groups generate FRAGOs assigning specific 
missions to squadrons and aircrews. Control agencies review, manipulate, and manually 
record the ATO onto report in/out (RIO) forms/logs and time-lines in preparation of 


controlling and directing the aircraft. 


F. LESSONS LEARNED FROM OPERATION DESERT STORM 

The IDASC (Improved DASC) Users Conference was held 8-12 April, 1991 at 
Mare Island, California following Operation Desert Storm primarily to "get a consensus 
of the air support control community on the priority and nature of proposed requirements 
(IDASC project).” (Report of Travel/Conference, 1 May 1991, p. 1) Receipt of the ATO 
was a main discussion item of the air support control community at this conference as the 
following item reflects: 

e "SUBJECT: RECEIPT OF THE ATO 


e DISCUSSION: The Joint ATO, issued by the Air Force was upwards of 700 pages 
long and originally was received via the Division Communications Center. Later, 
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it was scrubbed by the TACC and sent to the DASC via LAN. Received by the 
DASC on a UYQ-85, it arrived as two documents, a fixed wing and helicopter 
ATO. The scrubbed version, however, did not include other services aircraft. 
While the large joint version was still available via the communications center, 
significant effort was necessary to glean out the applicable missions from this 
unabridged version. While a standard MTF format was used, some Marines stated 
that some standardization still needed to be set down. 


IMPACT: The DASC needs the ATO in a timely manner and in a useful format. 
Consistent, successful receipt via the LAN on Desert Storm seems to suggest that 
this is a good way to receive the ATO provided that the LAN is available. The 
other ways of receiving the ATO (courier, teletype, tactical FAX) are still available 
if a LAN isn’t. 


- Ideally, the DASC would need to be capable of receiving the ATO either directly 


from the joint level or from the Marine Corps TACC. In either case we would like 
to be able to manipulate the ATO in such a form as to be readily usable to the 
aircraft directors, the SAD and anyone else who needs it. (Many man-hours are 
spent "busting the frag:" copying the applicable portions of the ATO onto RIO 
sheets and/or making up time-lines so that it is usable) 
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- If we have the luxury of receiving the ATO digitally, a manipulative program in the 
UYK-85 could be used to separate out helos from fixed wing, arrange the 
information into kinds of columns that we like to see, filter out unnecessary 
information, make up time lines to show mission groupings, and generally save time 
and effort. One Marine using such a program could prepare RIO sheets for the 
directors and time lines for the SAD in minutes. For record purposes, information 
could be quickly extracted by mission type, ordnance type, aircraft type, etc., and 
sent to the TACC without taking up a lot of valuable time..." (Desert Storm Initial 
Debrief Synopsis, 9 April 1991, p. 6) 

The users identified the following required capabilities during Phase II (selected 


automation) of the IDASC project in order of prionty: 


1. Receive and print out the ATO in MTF or MTS format. 
2. Manipulate the ATO into formats desired by the user. 
3. Receive and print out PLRS information. 

4. Send, receive and print out DCT messages. 


5. Automatically record and file Tactical Air Request (TAR’s), Bomb 
Damage Assessments (BDA’s) and other DASC related information. 


6. Extract statistical information from automated files. 


G. SUMMARY 

It is necessary to realize that the Marine Air Command and Control System is 
fundamentally a tool that decision makers use. It is a collection of equipment, personnel, 
and procedures that help the ACE commander gather, process, and disseminate 
information. Within the present DASC, coordination of air support requests with the 
FSCC, the receipt, storage, display, manipulation, and dissemination of the ATO and 
FRAGOs, and retrial and display of operational data are largely manual. The system is 


rapidly becoming deficient in its ability to perform its tasks. An increasing amount of 
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information has generated the need for selective automation of parts of the system. Given 
the current DASC and the related ATO operations, what aspects of the overall process can 
be automated effectively? The next chapter specifies requirements which address this 


question. 
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IU. DASC/ATO REQUIREMENTS 


A. GENERAL 
This chapter discusses the following issues involved when designing a database 
processing system for the DASC: 
- information processing requirements 
- hardware concepts and problems in the battlefield environment 
- man-machine interface considerations 
- data communications 
- interoperability 
e system security issues 
Background information about the IDASC project will be summarized first to show 
the constraints and scope of the needed database application. Internal and external 
interaction requirements and constraints of the system will be briefly discussed to 
determine the demands placed on the design of the equipment and the applications. The 
information flow requirements discussed last will serve as a blueprint for database design 


and implementation addressed in Chapters IV and V. 


B. IDASC PROJECT SUMMARY 
The IDASC is the designation given to the AN/TSQ-155(V) operations shelter. The 


shelter houses the personnel and equipement required of the DASC to perform its mission. 
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To avoid confusion because of pending modifications, the IDASC will be referred to as 
the AN/TSQ-155 when in reference to the system or DASC when implying the 
operational function. The DASC supporting system prior to the AN/TSQ-155 was fielded 
during the 1960’s and was designated the AN/TSQ-122. The AN/TSQ-122 was unable 
to satisfy increasing operational requirements and was fully replaced in 1989 by the 
AN/TSQ-155. The acquisition was initiated to satisfy requirements exclusive to the U.S. 
Marine Corps. There was no joint or foreign service participation. During May 1989, 
the Naval Electronics Systems Engineering Center (NAVELEXCEN) was tasked to act 
as the In-Service Engineering Agent (ISEA) for the IDASC improvement program. After 
reviewing operational effectiveness, it was determined that operational deficiencies existed 
and the Required Operational Capability for the DASC was revised leading to a phased 
system upgrade. 

Phase | modifications to the AN/TSQ-155 are near completion. Phase II (selected 
automation) and phase III (downsizing/improved mobility) upgrades will be accomplished 
concurrently by coordinated design/developmental tasks that will create a new entity for 
the DASC, a vehicle mounted shelter with an integrated command post extension tent and 
equipment that will provide automated capability. The automated capability improvement 
will be compatible with and interchangeable between the "Mobile DASC" and the 
AN/TSQ-155. 

A primary goal is to populate the DASC with Non-Developmental Item (NDD or 
off the shelf computer equipment and software. The system will use hardware from the 


Marine Tactical Command and Control System (MTACCS) Common Hardware System 
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(MCHS) and will consist of rugged computers capable of handling a large volume of 
information. The DASC computer terminal will be capable of interfacing with a variety 
of communications equipment to include tactical radios, tactical switches, tactical FAX, 
and tactical LANs. 

The DASC system will incorporate software from the MTACCS Common 
Application Support Software (MCASS). System software will provide the DASC with 
a set of automated tools to assist in the performance of its functions. These tools should 
have the following capabilities: word processing, message preparation and processing, 
tactical information database, digital message management system, overlay generation and 
distribution, database management system, database query capability, and hard copy text 
and graphics. These tools will enable the DASC to fulfill the user requirements of 
updating, displaying, and controlling the ATO and DASC related information from 
automated files. Application software will reflect the specific requirements of the DASC 
and be capable of running on the system hardware and use system software. Additionally, 
each operator requires a position which provides a workstation and allows individual 


access to intercommunications and common display information. (Draft ROC, p. 11) 


C. BATTLEFIELD REQUIREMENTS 

The hardware and software used by the DASC must be able to operate in all combat 
environmental conditions. It must be capable of operating in a tent or open field while 
mounted in military vehicles, and be transportable with ruggedized carrying/shipping 


boxes. Physical environment factors to be considered include temperature, humidity, sand 
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and dust, air pressure, shock and vibration, rain, fog, and salt water. Furthermore, 
electromagnetic pulse (EMP) and interference, as well as radiation security (TEMPEST) 
standards must be met. Finally materials used must be resistant to chemical agents and 
chemical decontaminants. Human factors engineering must be applied to allow human 
operators in all mission-oriented protective postures to use the machines in the battlefield 
environment. The size and weight of the components should allow for ’one-marine 
carry’. The system should have visual indicators and messages easily readable in all 
ambient light conditions. The storage hardware must be capable of rapid emergency 
destruction to enable protection of classified data. Redundancy both in data storage and 
power requirements must also be planned. These battlefield environmental constraints 
will have an effect on the physical design of the hardware as well as the architecture of 


the whole system including its interfaces. 


D. SYSTEM INTERFACES 

The DASC must interface with agencies internal and external to the MAGTF. In 
order to fulfill these requirements, numerous intra/interoperability interface networks have 
been constructed; however, some interoperability requirements are projected as future 
requirements. 

The system must also interface with the required MACCS and MTACCS agencies. 
Projected interoperability interfaces include elements of the Naval Tactical Air Control 
System (NTACS), the Air Force Tactical Air Control System (TACS), the Army 


Command and Control System (ACCS), and allied air support control units as required. 
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The DASC system will affect interoperability in accordance with the Marine Tactical 
System Technical Interface Design Plan (MTS TIPD) and United States Message Text 


Format (USMTF). 


1. Marine Tactical System 

The MTS TIDP provides USMC Tactical Data Systems (TDSs) with 
intraoperability message, data elements, and protocol standards. The interface design plan 
decomposes Marine Corps Command and Control Facilities (C2FACs) of the MTACCS 
interface requirements into specific data link protocol and message/data implementation 
requirements. It also provides the data element standard for data field identifiers (DFIs), 
data use identifiers (DUIs), and data items (DIs) that support the MTS standards. The 
message standards in volume IV of the TIDP contains approved Marine Corps messages 
with information on message purpose, structure, data content, and format. The 
transmission format (physical order and sequence of the fields) are presented on text 
information sheets within the TIDP. The MTS Message Formatting protocol provides 
message formatting that allows the system to be independent of the communications 


system. 


2. Message Text Format 
The USMTF program is designed to provide a uniform reporting procedure to 
be used in all defense conditions and to reduce the time required to draft, transmit, 
analyze, interpret, and process messages. The message text format (MTF) program 


improves information exchange by producing messages which are both human readable 
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and machine compatible. The program also has the objective of facilitating the exchange 
of information between the United States and Allied commands and reducing or 
eliminating dual reporting by US units when they operate with Allied command/units. 
The MTF program describes what 1s in reality an artificial language with its own definite 
structure, vocabulary, and syntax. The MTF ATO message format is listed in Appendix 


C 


3. Communications 

Communications requirement considerations include capacity, response time, 
connecting and addressing, integrity, control, security, and transmission medium. The 
demand for communication will not be constant but the demands for data transmission 
capacity and response time must be met by the communications system. Connecting and 
addressing protocols must provide a means for identifying the intended recipient of a 
transmission. The transmission medium must preserve the integrity of the information 
it handles. Control protocols must be applied to channel and transmission medium 
between computer-based information systems. The security of the information must be 
preserved by the communication system. Redundancy in the transmission medium must 
be planned. This redundancy may be single or multi-channel radio, satellite 


communications, copper cables or fiber optics. 
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E. MAN-MACHINE INTERFACE 

Rice states that "the design of the ... man-machine interface (MMJ) will be crucial 
to the efficient working of the system ... it provides the user with a window through 
which he may view the system and a set of controls to enable him to drive it.” (Rice, p. 
82) Simple interfaces consist of a way to insert/extract information into/from the system, 
and to direct the system what actions to take. The MMI includes the hardware and the 
software for this process. The dialogue used in this process determines how "user- 
friendly” the system is. 

Input devices consist of keyboards and pointing devices. A pointing device such 
as a tracker ball or mouse moves a symbol on the display to a desired position. Pointing 
to the desired position on the screen itself with a finger or instrument is another type of 
input. 

Output devices include either temporary or permanent display units. Temporary 
displays consist of visual display units such as cathode ray tubes (CRT), liquid crystal 
displays (LCD), gas plasma display, and projected displays. Permanent displays which 
deliver a hard copy may be either printers or plotters. Printers are usually limited to text 
or simple graphics while plotters can produce images along an x and y axis. Laser 
printers combine the qualities of both a printer and a plotter. 

Other interface technologies under consideration are voice recognition for input and 
speech synthesizers for output. 

The design of the dialogue between man and machine will determine how the user 


interacts with the system. The MMI should be easy to use for both the inexperienced and 
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the familiar user, consistent, and optimized for the task being performed. (Rice, p. 96) 
À context-sensitive “help” key which explains the task being performed is an example of 
this trait. Consistency standardization refers to the way tasks are to be performed. A 
simplified example of inconsistency would be mnputing ’Y’ or ’N’ in one application 
program while requiring "YES’ and ’NO’ in another. Pointing devices should also 
maintain consistent operations. Optimization for the task being performed means that the 
user should not have to access a large number of displays to perform his job. 

Styles of MMI that conform to the requirements above include a keyboard based 
MMI, a touchscreen based MMI, and the windows, icons, menus and pointer (WIMP) 
approach to MMI. (Rice, p. 98) Menu selection refers to a range of choices presented to 
the user on the screen. The input by the user will lead to other menus or to the task 
requiring performance such as entering form information. These layers of menus are 
referred to as the depth of the application and may be described as a tree structure. 
Experienced users should be able to jump between layers, while a user who finds himself 
confused about his location in the menu dialogue should be able to retum directly to the 
main menu. 

Keyboard based MMI are useful in data entry systems. A menu can lead the user 
to the correct form and then a form layout can assist the user in entering information. 
Shaded areas can highlight required inputs. 

Touch screens can be interchanged or incorporated with keyboard based MMIs, 
using graphical representations that prompt the user to touch the screen for the desired 


result. 
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The WIMP approach to MMI offers benefits which include consistency and multiple 
tasking. Windows are an area of the screen dedicated to a particular task. Icons 
graphically represent a resource or action to be preformed. When combined, they 
approximate the way a user may organize his tasks. 

The following examples of consistency include retrieval and saving of documents. 
All files are opened by pointing to an associated icon. Saving a file is accomplished by 
‘dragging’ it to a file cabinet icon and then clicking a button on the mouse to indicate the 
document is to be saved. 

Multiple tasking involves being able to work on two or more applications at the 
same time. For example, while working on a word processing document, the user may 
open a window, retrieve data from a spreadsheet and then ’cut and paste’ this information 
into the original document. This example of multiple tasking demonstrates one of the 
advantages of the WIMP or graphical user interface (GUI) approach to MMIs. 

The choice of MMI will be determined by the required tasks and battlefield 
environment. Because the users in the air support community are often resistant to 
automation, these design decisions are critical to the acceptance of the entire system. 
Automation must both improve efficiency through user friendliness, and provide useful 
information. MCTSSA, representing the user community, must stress the importance of 
user friendliness and insure user involvement with the designers, developers and 


programmers of the MMI. 
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F. INFORMATION FLOW REQUIREMENTS 

Although the DASC consists of many crew members performing separate functions, 
we will treat the DASC as a "black box” and concern ourselves with the external 
information flow of the DASC rather than the internal coordination of the DASC crew. 
The DASC crew will interact with different applications designed for their specific 
functions. The information flow of the DASC that pertains to the user requirements 
defined in Chapter II is depicted in Figure 5 and includes: the ATO, mission requests, 
mission status, aircraft status, and battle damage assessments. Each is considered in turn. 


The appropriate forms are displayed in Appendix 3. 





Figure 5. DASC Information Flow 
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1. ATO 
The ATO is received by the DASC daily. Updates or changes to the ATO can 
be received at any time. The MTS message includes the effective time period, tasked 
unit(s), and basic mission information: mission number, request number, priority, mission 
type, time on and off target, alert status, location, callsign, number and type of aircraft, 


ordanance type, IFF/SIF mode and code, and time and target location. 


2. Mission Status 
Mission status refers to the information that an appropriate MTACCS agency 
sends or requests on aircraft assignment data. The status may pertain to preplanned, on- 


call, or immediate missions. The information may pertain to any data on the ATO. 


3. Mission Requests 
Requests to the DASC for direct air support can come in the form of tactical 
air requests or assault support requests. Voice communications discussed in current 
operations use the JTAR or ASR forms. MTF message standards utilize the Air Support 
Request (AIRSUPREQ) format. The DASC may assign subordinate controlling agencies 
mission data and brief the aircrew using the 9-line brief format. 
d Aircraft Status 
Aircraft status/availability reports are made to the DASC pertaining to aircraft 
in a strip alert status. If the DASC has launch authority of the aircraft, information would 
include number and type of aircraft available during specific time periods with specific 


ordnance and strip alert times. 
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5. Battle Damage Assessment 
The purpose of the BDA is to convey the pilots’ or controllers’ damage 
assessment, ordnance expended, and ordnance remaining. The DASC receives the 


information and relays it to the appropriate MTACCS agency. 


6. Reports 
The DASC may be required to submit operational summary reports based on 


the operational events during a specified period. 


G. SUMMARY 

The DASC system requirements discussed in this chapter defined the computer 
hardware, software, security and communications considerations that require attention 
when designing systems that can survive on the battlefield. By establishing the 
information exchange requirement of the users as applied to the ATO, we are now able 


to look at database processing alternatives for developing a database application for the 


DASC. 
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IV. DASC DATABASE APPLICATION 


A. GENERAL 

The user requirements and information flow discussed in the previous chapters will 
provide the basis for the logical database design developed in this chapter. The Entity- 
Relationship (E-R) approach is utilized to develop the logical database design. The data 
is normalized using an E-R modeling tool. The use of these methods will demonstrate 


the potential for designing and implementing a relational database application within the 


DASC. 


B. DATABASE OVERVIEW 

Database technology was developed to overcome the limitations of file processing 
systems. In database systems, all application data are stored in a single repository called 
a database. (Kroenke, p. 10) It is a collection of related data designed and built for a 
specific purpose, intended for use by a known group of users, representing some aspect 
of the real world. Database processing eliminates the dependency of programs on specific 
file formats which cannot be shared easily by other programs. DB processing allows 
different users to share the same data thus minimizing duplication and update problems 
caused by redundant data in file processing systems. Unlike file processing programs, 
database processing programs do not require file and record formats. (Kroenke, 1987, p. 


11) File formats are stored in the database and accessed by a database management 
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system (DBMS). This arrangement of data, called program/data independence, is the 
primary objective of a DBMS. 

Database applications are developed so users in different functional areas can 
retrieve information from a common database without interfering with one another. 
Database systems provide mechanisms for updating, displaying, and controlling the data. 

À database model is a representation of a physical database. It shows the physical 
files, the access paths between the files, and the data items in each file. Database models 
are defined by the way data is organized, stored, and manipulated. Traditional file 
processing systems use flat files where relations between files are defined by the 
application programmer. The emergence of DBMSs led to different concepts in database 
architecture, and the way data 1s linked to the database and the application. 

The primary database models are the hierarchical, network, and relational models. 
In the hierarchical and network models, the application programmer must know the 
physical structure in order to navigate through the database. This structure can become 
very complex to learn and is quite demanding on the user and/or programmer interacting 
with the database. The conceptual structure matches the physical structure tying the data 
to the application. This results in a high level of maintenance because changes in the 
application data requirements force changes in the defined data structures. (Brackett, 1987, 
p. 6) These weaknesses have led to a third method of data modeling based on relational 
theory. 

Relational database architecture is an environment in which data are viewed as 


tables, or relations,and multiple tables can be associated or related to one another based 
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on common data items or fields within the tables. The physical relationships are defined 
at execution time based on the application needs. This model contrasts with the 
hierarchial or network models which require pointers or links in each data record. Since 
there are no predefined relationships in relational databases, the structural detail is 
minimized. This results in lower database maintenance, making it easier to control 
database changes, and provides flexibility by facilitating the definition of dynamic logical 
relationships (Brackett, 1987, p. 5-6). Reports or processes can be added without having 
to modify the structure, and changes made to a data item will be reflected in every related 
record. 

Knowledge of relational model terminology will assist in understanding the logical 
database design presented below. The relational data model files appear as flat files, or 
tables to the users. A relation is a table containing data about an entity or object that 
obeys certain rules. An entity is a real world thing. Each relation deals with a single 
entity and each row in the relation is an instance or occurrence of an entity. A tuple is 
a row in the table, an attribute is a column. There is no order to the tuples and attributes. 
Each attribute has a domain of values which can be assigned to any instance of an 
attribute. A key is a group of one or more attributes that uniquely identifies a row. The 
primary key is a unique identifier for the table. A foreign key is an attribute on a 
relation that contains the primary key of another relation in order to relate one table to 


another. Figure 6 is an example of a relation. 
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LOCATION 


A PRG Y 


Figure 6. Example of a Relation 


C. DATABASE DESIGN 

The goal of the design phase is to develop a model for one or more applications 
that will support current and future operations. Database design includes the definition 
of tables, attributes, and relationships among tables. The design methodology used in this 
thesis is summarized in Figure 7. 

The schema is a formal definition of the logical records that make up the database 
and the ways that relationships among records are represented. Logical database design 
transforms the formal representation of entities and their relationships, called a conceptual 
schema, into a processable schema for a given system application. The logical data 
structure (LDS) is a graphical depiction of the four components: entity, attribute, 


identifier, and relationship. The identifier describes the entity, attribute, or relationship 
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ANALYZE DATA 
NEEDS ANALYSIS 
DEVELOP 


RECONCILE 


BUILD DATABASE 





Braune 7. Database Design Process 


(e.g., LOCN identifies an attribute in Figure 6). A collection of LDSs describing the 
conceptual information structure is determined by the user. For the DASC application, 
the database requirements defined in the Information Flow Requirements section of 
Chapter III require that the user be able to receive the ATO, to archive and extract 
information from it, and manipulate it into desired formats. The ability to record and file 
immediate requests, BDAs, and other DASC related information, and to query the 
database to extract statistical information is also required. Entity-Relationship modeling, 
a top down approach to data modeling, helps the designer to capture data requirements 


and transform them into a logical data structure and user schema. 
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1. Entity-Relationship Model 
The Entity-Relationship (E-R) approach is unique among database design 
techniques in that it can be used to design a database independent of the underlying 
database model (hierarchical, network, relational). It is based on a theoretical foundation 
of relational algebra, and aids in communication between designers and users. The E-R 


modeling steps are: 


1. classification of entities and attributes 

2. identification of generalization hierarchies 

3. determination of the relationships among the entities 

4. definition of the mapping cardinality between each relationship and entity. 

(Teorey, 1990, p. 55) 
The E-R model uses entities to represent a real world thing, object, or concept 

(e.g., ATO). Entities contain descriptive information called attributes (e.g., ATO contains 
Start Time, and Stop Time). Attributes that may be repeated in an entity are called 
multivalued attributes, and will be classified as separate entities (e.g., ATO has a repeating 
ATO Mission field, will be decomposed into a separate ATO Mission entity). Attributes 
should be attached to the entity they best describe. An entity can usually be described 
by a noun. If one entity is dependent on the existence of another entity (e.g., Mission 
Data is dependent upon ATO), then that entity is described as a weak entity. A gerund 


is a relationship converted to an entity (e.g., customer ships a product, but the shipping 
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is done by clerks). If entities relate to themselves (e.g., person-married-person), then the 
relationship is called recursive. 

A relationship is an association between two or more entities. Relationships 
are usually described by verbs in the E-R diagram (e.g., ATO contains Mission Data). 
The degree of a relationship is the number of entities associated with the relationship. 
A relationship with n associated entities is called n-ary (e.g., unary (1), binary (2), and 
ternary (3)). An entity is a temary relationship if an instance of an entity can be 
associated with one instance of each of two associated entities. An example is the three 
entities Mission, JTAR, and Unit associated by the relationship “requests”. 

Values associated with the connectivity between entities are "one" or ‘many’. 
The number associated with the term “many” is called the cardinality of the connectivity. 
Functional dependency refers to the relationship between attributes. If, when given a 
value of attribute x, one can determine the value of attribute y, then y is said to be 
functionally dependent on x. When two attributes functionally determine each other, a 
1:1 relationship occurs (e.g., Control Agency determines Callsign, and Callsign determines 
Control Agency). If one attribute functionally determines another but not the reverse, a 
1:M relationship occurs (e.g., Callsign determines Mission Number, but Mission Number 
does not determine Callsign). Finally, if neither attribute is functionally dependent on the 
other, a M:M relationship occurs (e.g., Mission Number and Request Number do not 
determine each other). (Kroenke, 1987, p. 163) 

Participation rules may also pertain between entities. Obligatory participation 


requires that every instance of an entity must participate in a relationship (e.g., all BDAs 
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must be assigned to a Target). Non-obligatory participation is an instance of an entity 
mot needed to participate in a relationship (i.e. a BDA may exist with no JTARs). A 
generalization/specialization (JSA) occurs in a relationship when an entity is partitioned 
by different instances of a common attribute. An example is the entities Mission Location 
and Target Location which share the common attribute Location, but have distinct 
attributes associated only with that generalization/specialization (e.g., Mission Location 
has the attribute Location Type, while Target Location has the attribute Target Type). In 
the example above, ATO Mission can contain either a Target Location or a Mission 
Location. 

When translating the E-R model to the relational approach, each entity 
becomes a table, each attribute becomes a column in the table, the unique identifier 
becomes the primary key, and that primary key becomes a foreign key on the many side 


of 1:M relationships. 


2. Normalization 
Relations are often defined in a form that suffers from problems in terms of 
integrity and maintainability. Updates to a database may result in the elimination of 
useful data as an unwanted side effect. Also, when the data is defined as a single large 
table, updates can result in large amounts of redundant data. Classes of relational 
database forms, called normal forms, are defined to avoid these problems and maintain 
high integrity and maintainability. The process of creating the appropriate normal forms 


is called normalization. (Teorey, 1990, p. 91) 
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Normalization is a process of assigning attributes to the appropriate entities. 
It is a bottom up approach to data modeling. The principles of normalization dictate that 
data items belong together in a logical group, and these groups can be identified by their 
own unique identifier or key. The data in each group should describe one, and only one 
thing. Normalization for the relational model usually requires normalizing relations to 
Boyce-Codd Form, or the equivalent as defined below. 

Recalling the definitions of a relational data model, all relations are said to be 
in first normal form (1NF) 1f they have non-repeating groups within a tuple. Consider 
the relation: 

ROUTE (Point Number, Location) 
where Location represents the location of a point. This is a repeating group for multiple 
missions because different locations may be assigned the same point number for separate 
missions. To fix this, the relation would become: 

ROUTE (Point Number, Mission Number, Location) 
where each location would have a separate tuple. 

A relation is in second normal form (2NF) if it is in INF and all non-key 
attributes are dependent on the primary key. An example would be the Route relation 
used earlier: 

ROUTE (Point Number, Mission Number, Location, Mission Type) where 
Mission Number --> Mission Type 
The non-key attribute is dependent on part of the primary key. To fix this the relation 


is decomposed into the following two relations: 
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ROUTE (Point Number, Mission Number, Location) 
MISSION (Mission Number, Mission Type) 

A relation ıs in third normal form (3NF) if the above exists and there is no 
non-key attribute determined by anything but the key (transitive dependency). A relation 
in violation of third normal form would be: 

ROUTE (Point Number, Mission Number, Location, Location Comments) 
where Point Number, Mission Number --> Location 

Location --> Location Comment 
This is in violation because Location, a non-key attribute determines Location Comment, 
another non-key attribute. This is fixed by decomposing the relation into two relations: 

ROUTE (Point Number, Mission Number, Location) 
LOCATION (Location, Location Comments) 

Finally, a relation is im Boyce-Codd Normal Form (BCNF) if every 
determinant is a candidate key, or no anomalies regarding functional dependencies exist. 
BCNF deals with relations with overlapping keys. An example of a relation with 
overlapping keys is: 

ROUTE (Point Number, Mission Number, Location, Point Name) 
where Point Number, Mission Number --> Point Name 

Point Number, Location --> Point Name 
These are overlapping keys because both keys contain Point Number. To fix this 
problem, the relation is decomposed into two relations: 


ROUTE (Point Number, Mission Number, Location) 
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POINT (Point Number, Point Name) 

A decomposition is said to be lossless if it preserves the functional 
dependencies of the original relation. For example if the two decomposed relations above 
are joined, the resulting relation will be equal to the original relation. 

The bottom-up, or normalization approach in developing a logical database 
design will result in the relations being normalized to the degree required, usually, a 
collection of tables in BCNF. The resulting processable schema allows the DBMS to 


physically manage the database. 


D. SCENARIO 

To model the user defined requirements, a simple scenario will be described based 
on current operations in the DASC. The DASC will be treated as a "black box" Le., 
ignoring its internal functions. Likewise, external agencies wil be ignored. The E-R 
model is concerned only with the information requirements of the DASC, not the means 
by which information was transmitted or received, or its origin or destination. 

The scenario is as follows: 

l. The DASC receives the ATO and manipulates it for display on the 
appropriate log (FRAG). 


2. The DASC receives JTAR 26-1 and processes it, assigning a mission to 
execute it. 


3. The DASC transmits mission data to the requestor and requests launch of 
the assigned mission. 
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The aircraft reports to the DASC, the DASC briefs the A/C using the 9- 
line brief format, and turns the A/C over to the terminal controller at the 
appropriate control point. 


The DASC requests mission status on a Totary wing mission. 


The A/C executing JTAR 26-1 checks out with the DASC, mission 
complete, with aBDA. 


The DASC receives a change to a preplanned mission. 


At the end of the day, the DASC transmits an operational summary 
(OPSUM) report. 


DASC DATABASE DESIGN 


Relational database application capabilities will be demonstrated by extracting 


information from the current databases used in the DASC. This involves combining the 


automated files (MTS ATO), non-automated data (immediate requests, RIO logs, BDAs, 


operational summary), and user requirements discussed in Chapter DI. 


This information provides the basis for determining the entities, attributes, and 


relationships for the E-R diagram. The abbreviations and field structures of the identifiers 


duplicated the existing MTF and report formats where applicable. The following entities 


were identified to pertain to the DASC ATO application: 


a 


AIR TASKING ORDER - defines time period and type of ATO 
BATTLE DAMAGE ASSESSMENT - defines mission results of a particular target 
CONTROL AGENCY - defines characteristics of a particular control agency 


IMMEDIATE REQUESTS - defines unit supported for an immediate air support 
request 
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- MISSION (ATO MISSION) - defines basic characteristics of the particular mission 
to include aircraft data 


- MISSION LOCATION - defines mission location 
- RECEIVING AIRCRAFT - defines mission data for aircraft requiring refueling 
+ RECONNAISSANCE - defines reconnaissance data 
- RECON TARGET - defines reconnaissance target data 
e RIO LOGS - defines actual mission data 
- ROUTE - defines mission route information 
- TARGET LOCATION - defines mission target data 
The relationships defined between entities depicted in Figure 8 include: 
- ASSESSES - BDA may be reported on a TARGET LOCATION 
- COMPRISES - ATO is comprised of various MISSIONs 
- CONTROLS - MISSION is controlled by various CONTROL AGENCY (ies) 


- INTEREST IN - RECONNAISSANCE mission executes vanous RECON 
TARGETs 


- MAY DESIGNATE - MISSIONs may follow certain ROUTEs 
* REFUELS - MISSION LOCATION may refuel RECEIVING AIRCRAFT 
- REQUESTS - IMMEDIATE REQUESTS request MISSION to perform 
- UPDATES - RIO LOGS update the ATO with actual mission data 
Mapping cardinality between each entity was specified to complete the diagram. 
Appendix D lists the cardinality rules used for each link. 
Figure 8 depicts the resulting E-R diagram using an E-R modeling tool called E-R 


Designer by Peter Chen and Associates. Appendix D lists and explains the entities, 
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attributes, relationships, and cardinality rules depicted on the E-R diagram. 

The entities BDA and Target Location linked by the relationship Assesses will be 
used as an example of how to read the diagram: There can be as few as zero or as many 
as N (many) BDAs assessing each Target Location; and there can be one and only one 
Target Location assessed in each BDA. The term ’ISA’ refers to a generalization 
occurrence on the entity ATO Mission. ATO Mission must have one of the entities; 
Target Location, Mission Location or Reconnaissance, as a member. 

The E-R model was then loaded into the Normalizer tool of E-R Designer to 
validate the schema. The initial schema generated by the E-R Designer tool is shown in 
Appendix E. Functional dependencies (FD) were defined in each relation. The 
normalizer tool normalized the relations to the BCNF and decomposed the relations into 
FD-preserving and lossless-join 3NF relations. It also ensured that complex relations 
were broken down into simpler ones in which related data items were grouped and 
duplication minimized. The user interaction log for defining the functional dependencies 
is listed in Appendix F. The resulting schema from the Normalizer tool 1s displayed in 


Appendix G. 


F. IMPLEMENTING THE DASC SCHEMA ON A RELATIONAL DBMS 
The relational schema developed in the previous section is not linked to any specific 
DBMS. No database package meets all the features and qualifications of a "fully 


relational” database; however, many relational databases exist that can use the schema 
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generated. To demonstrate the potential of a relational database, dBASE IV is used as 
a prototype implementation of the DASC application. 

A DBMS is a program, or set of programs, that processes the database. The DBMS 
allows the user to create, maintain, and access a database. The DBMS allows the 
program to be separate from the application. The application can be thought of as a 
collection of menus, forms, reports, and programs that satisfies the needs of a user or 
group of users. The DBMS is a set of programs or tools which allows developers to 
design and implement a system which users can access. (Kroenke, 1987, p. 62) The 
features and functions of a DBMS include: 

- Change the data as the real world changes 

- Support a data structure that corresponds to the real world 
- Protect the data from corruption from authorized users 

- Protect the data from unauthorized users 

- Support access to data by multiple users simultaneously 

- Recover from software and hardware failures 

- Get information out of the database easily 

- Improve productivity of the development programmers 

- Reasonable performance 

A database was created using the normalized relational schema field format 
developed by E-R Designer. A simulated ATO was loaded into the database. Reports 


were generated linking tables to get the desired outputs. Ad hoc queries were conducted 
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to determine the application capabilities. Sample reports and queries are listed in 
Appendix H. 

Database generation creates an actual physical structure which is generated from the 
conceptual schema. The DASC application schema created by E-R Designer and listed 
in Appendix G determined: 

e database names 
- field names 

- field types 

e field length 

The data files created above were used to define the database structure in dBASE 
IV. dBASE IV uses a main menu called the Control Center to access and store files. 
dBASE IV achieves the functions of data management (creation, interrogation, updating, 
administration) through the Control Center. For example, the relation Air Tasking Order 
was used to create the database file ATO in the Data Panel. Field names were derived 
from the attributes ATO Start, ATO Stop, and Air Tasking Code using the attribute type 
(character or numeric) and length as shown in Appendix G. 

Unless otherwise specified, dBASE IV stores records in the order in which they are 
entered. dBASE IV can be manipulated to store and retrieve data in a sorted order by 
physically rearranging the records. Another way to sort, or retrieve, data 1s by creating 
an index field on a field value. Indexes allow data to be retrieved “directly” rather than 


by doing a sequential search, thus indexing makes some retrievals more efficient. For 


49 


example. since the DASC ATO application will require information on particular mission 
numbers, the Mission Number field was indexed when delineated in a database (relation). 

Once the database structures were created, data was loaded into the appropriate 
databases. An ATO was developed consisting of seven missions. Manual insertion of 
data was done ensuring all tables contained some data. The actual DASC application will 
require a compiling program and parser to automatically upload MTS data to the DASC 
application. 

The next step was to create database queries and views. A query is the retrieval of 
a specific table, possibly requiring the join of two or more tables, to meet a stated 
condition. Queries may require that data be drawn from multiple tables. dBASE IV uses 
views to help with query operations. In general, a view is a virtual table which is a 
subset of one or more existing tables in the database. In dBASE IV, it’s actually stored 
physically but this is not how all DBMSs do views. For example, a mission status may 
be requested on a troop lift from the DASC. The DASC would use the DASC application 
to find this information by creating a view linking the attributes of A/C Status database 
with the A/C Weapons database. A query is made on this view listing all records whose 
A/C Type field type is "CH-46". This query would create a view of the mission data of 
mission "30H0002". These queries can be permanently stored in the Queries panel of the 
control center in dBASE IV. 

Forms files display customized screens. This can be used for entering, updating and 


displaying data on a particular form. The custom form can be created using the tools in 
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dBASE IV. An example is the Battle Damage Assessment form contained in Appendix 
H. Forms may also be created using the special views created in the queries panel. 

Reports can be generated in dBASE IV from one or more tables using the above 
procedures. The reports can be printed or displayed on screen. Appendix H contains a 
sample Report-In/Out Log and Immediate Air Support Summary Report. 

Design and implementation of the DASC schema as described above is the 
responsibility of the Database Administrator (DBA). The DBA must ensure that the 
integrity of the underlying DASC database is maintained at all tumes. This entails a 


number of critical functions as described next. 


G. DATABASE ADMINISTRATION FOR THE DASC DATABASE 
Database Administration is a technical function that is responsible for physical 

database design and for dealing with technical issues such as security enforcement, 
database performance, and backup and recovery. (Hoffer, 1991, p. 339) The Database 
Administrator for the DASC database will need to be involved with the following: 

e referential integrity 

* concurrency control 

e backup and recovery 

e database security 

- handling missing data 


- training 
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J. Referential Integrity 

Referential integrity is concemed with the validity of references by one object 
in a database to some other object(s) in the database. Rows in one relation may refer to 
a row in another relation, and problems can occur when inserting/deleting data. A 
referential integrity constraint requires that for each row of one table, the "referencing 
table", the value of the foreign key value must be the same as the value of the 
corresponding primary key column in some row of the referenced table or else be null. 
À row should not be able to be inserted in the referencing table unless it exists in the 
referenced table. Additionally, a row should not be able to be deleted from the referenced 
table if there is a matching row in the referencing table. For example, if a mission is 


deleted from the A/C Status relation, then the deletion should either: 


l. be deleted in every relation which contains the same mission, 
2. be disallowed, or 


3. nullify the mission number attribute in the referencing table(s). 


Referential integrity constraints can be enforced by an application program or 
by a DBMS that includes facilities for enforcement. dBASE IV does not provide 


referential integrity facilities. 


2. Concurrency Control 
Concurrency in a database environment means that more than one user can 


access and manipulate data at the same time. Multiple users of the DASC database can 
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compromise the data unless there is concurrency control. An example would be where 
users A and B both update the relation Battle Damage Assessment. User A updates the 
field BDA Comment and saves the data, while user B updates the field Unit Supported 
and saves the data 5 seconds later. The information updated by user A would be lost. 
Controlling concurrent access may be done by locking or denying access to 
other users until the update is completed. Locks may be implemented at different levels 
(database, table, block, record, field), and may provide shared access but allow only one 
update user. DBMS products provide different locking capabilities. dBASE IV provides 
concurrency control by locking records automatically by default, or by locking table 


access through the protect and exclusive use commands in the application generator tool. 


3. Backup and Recovery 

Database recovery procedures are required to restore a database quickly after 
a loss or damage. The DBMS should have tools to recover data from program aborts, 
software failures, and hardware failures. In program aborts, the DBMS detects 
transactions started and aborted without "commit", then effects an automatic "rollback". 
When a system "crashes" or loses power, the DBMS examines the transaction log once 
initiated and effects a “rollback” for all incomplete transactions. The database must be 
restored from a backup copy for hardware failures, and the DBMS must reproduce 
transactions on log since the backup. dBASE IV, for example, provides automatic 
"rollback" through the application generator tool. dBASE IV also has the capability to 


log terminal activities into a text file to produce and an audit trail of database 
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transactions. This audit trail, however, cannot be automatically reapplied to restore the 


database. 


4. Database Security 
Data Security protects the data from unauthorized users. The first level of 
security is physical security. The next is the use of passwords both into the system and 
into the programs. The DBA can create views for different classes of users controlling 


the type of access (read, write, delete) each user has to the data. 


5. Handling Missing Data 
Procedures must be established by the database administrator to handle missing 
infonnation. Data that is missing, lost, or incomplete in the DASC application must be 


dealt with in the design phase. 


6. Training 
The DBA interfaces with the users for training purposes, and to determine 
ongoing system requirements. DBMS software is complex and consumes resources. 
Performance is measured in time required to support a function, number of users 
supported, and number of transactions per second. There is a trade-off between 
performance vs. features, performance vs. flexibility, and performance vs. portability. 
Reasonable performance will depend on the balance of these trade-offs. (Hoffer, 1991, 


p. 363-384) 
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D SUMMARY 

This chapter discussed and applied the relational theory for data modeling to the 
DASC application using the E-R approach and normalization. An entity-relationship 
model created by the support tool E-R Designer was combined with the Normalizer 
support tool to develop a relational schema for the DASC application. The logical data 
structure was translated to a relational schema, and implemented on a microcomputer 
DBMS called dBASE IV. Although further work 1s needed before the DASC application 
can be fully implemented as a functional prototype, the potential for this approach and 
resulting application was demonstrated. The Database Administrator will play a key role 
in developing the DASC ATO application. A DBMS that provides interactive 
management facilities will assist the DBA in his responsibilities. 

The final chapter summarizes the study’s results, and suggests areas for future 


study. 


SE 


V. CONCLUSIONS 


A. CONCLUSIONS 

This thesis developed a logical schema for a centralized relational database, given 
the requirement specifications for a DASC database application. The thesis illustrates the 
steps of E-R modeling, normalization, and implementation of the schema using a 
relational DBMS. Database design is an evolving activity. As user requirements expand 
and change, the conceptual schema and database structures must change accordingly. The 
methodology used in the original design 1s important since it may be reused to keep the 
database current as more aspects of the DASC application are developed. 

The E-R approach is particularly useful in the early stages of the database lifecycle, 
which involves requirements analysis and logical design. When requirements are 
determined from end-user interviews and modeled in terms of E-R diagrams, immediate 
feedback can be obtained concerning the validity of the database. Another advantage of 
the E-R approach is that the schema is independent of any particular DBMS environment 
and therefore can be used with potentially many different DBMS platforms. 

Once a logical data structure has been generated, it 1s a straightforward process to 
implement the schema in a specific environment as we have shown with dBASE IV. The 
relational DBMS manages ad hoc queries and new applications that would be more time 


consuming to implement with other models. 
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Relational databases are easy to design, maintain, and use. They enforce data 


independence and encourage data sharing. They readily support application development, 


prototyping, and distributed data applications. Relational architecture will support many 


applications and is recommended for adoption for implementation of the DASC 


application. 


B. 


FURTHER RESEARCH 


This thesis represents only an initial study into the potential of implementing a 


relational database application in the DASC. The study examined a passive DBMS where 


queries and transactions occurred only when explicitly requested by the user or 


application program. Future study is suggested in: 


design of an active database management system aimed at meeting the needs of 
applications requiring time-constrained data management and processing. A High 
Performance Active (HIPAC) DBMS automatically monitors events, evaluates 
conditions defined over the state of the database when appropriate events occur, 
and, based on the result of conditions evaluation, invokes actions associated with 
the event-condition pair. 


evaluation of implementing the database design in SYBASE, the Marine Corps’ 
chosen standard for relational DBMSs. 


evaluation of the alternative file indexing structures of the DASC application. This 
system performance evaluation should determine the structure with the best 
performance while minimizing the volume of the database. 


define the structure and content of a database that would support the entire Marine 
Air Command and Control System and Marine Tactical Command and Control 
System. Standardization of data elements used within the system should be 
addressed. Considerations should be given to implementing the design in a 
distributed database environment. 


e development of an expert system for assignment of missions to immediate air 
requests that interacts with the DASC application. The expert system could be 
based upon standard operating procedures to assist decision makers in the DASC. 


e determine the communication equipment requirements to include parser and 
compiling requirements for the transmission, receipt, and storage of the ATO. This 
should include security and integrity checking in the transmission specifications. 


APPENDIX A: GLOSSARY 


Anomaly - An undesirable consequence of a database modification. 


Application - A collection of menus, reports, forms, and programs that addresses the 
needs of the users. 


Attribute - A data element that describes an entity. A column of field in a relation. 
Candidate Key - An attribute or attribute group that could be used as a key in a relation. 


Command and Control Facility (C2FAC) - An organization element that needs to 
communicate with another to perform its tasks. 


Command and Control (C2) System - The facilities, equipment, communications, 
procedures, and personnel essential to a commander for planning, directing, and 
controlling operations of assigned forces pursuant to the missions assigned. 


Data - A fact or condition represented in a form that is usable by an Automated Data 
System including its operators. 


Data Item - The smallest unit of named data that has meaning in the real world. 

Data Dictionary - A user-accessible catalog of data about a database. 

Data Element - Used synonymously with data item. 

Data Field Identifier (DFT) - The DFI provides the identification for the class of data 
relating to a message field in the MTS message standard. The DFI contains a unique 
number, name, and definition. The DFI is a generic definition of the concept represented 
by all associated DUIs. All DFIs most have at least one associated DUI. 

Data Model - A language describing the structure and processing of a database. 

Data Use Identifier (DUD) - The DUI further identifies the functional or categorical 
context in which the DFI is used. The DUI contains a unique name among all DUIs and 


a unique number among the DUIs within the DFJ. All DUIs have at least one Data Item 
(DD or field or attribute. 
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Database - An organized and integrated collection of stored operational data used by an 
Automated Data System. 


Database Administrator - The person or group responsible for the design, creation, 
maintenance, and control of the database. 


Database Management System - A software function providing data handling services 
to operators (end users), application programmers, and Database Admunistrators. 


Entity - A real world object that is important to the system application. 
Entity Instance - An occurrence of an entity. 


Entity-Relationship Diagram - A diagram used in database design that illustrates entities 
and the associations among them. 


File - The collection of records of a single type. 
Foreign Key - An attribute that has a key of a different relation. 


Functional Dependency - Relationship between X and Y such that, given a value of X, 
one can determine the value of Y. Written as X -> Y. 


Wierarchical Data Model - A data model that such that each record has exactly one 
parent, except the root, which has no parent. 


Identifier - The attribute(s) and/or relationship(s) that uniquely identify a particular entity. 
Interoperability - The ability of systems, units, or forces to provide services to, and 
accept services from other systems, units, or forces, and to use the services exchanged to 
enable them to operate effectively together. 

Intraoperability - Interoperability among the Marine Corps systems. 


Key - A group of one or more attributes that uniquely identifies a row (tuple, record) 


Local Area Network - A collection of geographically close microcomputers that 
communicate. 


Meta-data - Data about the structure of a database that is stored in the data dictionary. 


Network Data Model - A data model in which all relationships are one-to-many and a 
child can have multiple parents as long as they are different record types. 
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Primary Key - An attribute or attribute group chosen as the key of a relation. 


Protocol - Communication protocols are processes or sets of rules controlling the 
interchange of information. 


Record - A group of related data items treated as a unit. 


Record Type - Defines the structure of a record by identifying the names of the data 
elements present. 


Record Occurrence - One particular instance of a record type with values assigned to 
the data elements. 


Relation - A two-dimensional table containing single valued entries and no duplicate 
rows. 


Relational Database - A database structured in accordance with the relational data model. 


Relational Data Model - A data model in which data is stored in tables, and association 
between tables are represented within the table data. 


Relationship - An association between two entities. 

Schema - A logical view of a database. 

Transitive Dependency - A relationship between attributes X, Y, and Z such that, if Y 
is determined by X, and Z is determined by Y, then Z is determine by X. Written as if 


X -> Y and Y -> Z, then X -> Z. 


Tuple - A row or record in a relation. 
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APPENDIX B: MILITARY ACRONYMS 


AAW - Antiair Warfare 

ACCS - Army Command and Control System 
ACE - Aviation Combat Element 

ASOC - Air Support Operations Center 

ASR - Assault Support Request 

ASRT - Air Support Radar Team 

ATO - Air Tasking Order 


BDA - Bomb Damage Assessment 


CAS - Close Air Support 

COC - Combat Operations Center 

CP - Command Post or Control Point 

CRLCMP - Computer Resources Life Cycle Management Plan 
C2 - Command and Control 

C2FAC - Command and Control Facility 

C3} - Command, Control, Communication and Intelligence 


DASC - Direct Air Support Center 

DCT - Digital Communications Terminal 
DFI - Data Field Identifier 

DI - Data Item 

DUI - Data Use Identifier 


EMP - Electro-magnetic Pulse 
EW/C - Early Warning/Control 


FAC - Forward Air Controller 

FAC(A) - Forward Air Controller (Airborne) 
KMFM - Fleet Marine Field Manual 
FRAGO - Fragmentation Operation Order 
FSCC - Fire Support Coordination Center 
FBC - Future Battle Cell 


GCE - Ground Combat Element 


HC(A) - Helicopter Coordinator (Airborne) 
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IDASC - Improved DASC (Facility) 
ISEA - In-service Engineering Agent 


JTAR - Joint Tactical Air Request 


LAAD - Low Altitude Air Defense 
LAAM - Light Antiaircraft Missile 


MACCS - Maine Air Command and Control System 


MACG - Marine Air Control Group 

MAGTE - Marine Air-Ground Task Force 

MATCS - Marine Air Traffic Control Squadron 

MCASS - MTACCS Common Application Support Software 
MCHS - MTACCS Common Hardware Suite 

MCTSSA - Marine Corps Tactical System Support Activity 

MMI - Man-machine Interface 

MTACCS - Marine Corps Tactical Command and Control System 
MTE - Message Text Format (also USMTF) 

MTS - Marine Tactical Systems 


NAVELEXCEN - Naval Electronics Systems Engineering Center 
NDI - Non-developmental Item 
NTACS - Naval Tactical Air Control System 


ORD - Operational Requirements Document 


PLRS - Position, Location, and Reporting System 
P31 - Pre-planned Product Improvement 


RAC - Refueling Area Coordinator 
RIO - Report in/out 

ROC - Required Operational Capability 
RPV - Remotely Piloted Vehicle 


SAAWC - Sector Antiair Warfare Coordinator 
SAD - Senior Air Director 


TAC - Tactical Air Commander 

TAC(A) - Tactical Air Coordinator (Airborne) 
TACC - Tactical Air Command Center (USMC) 
TACP - Tactical Air Control Party 

TACS - Tactical Air Control System (US Air Force) 
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TAOC - Tactical Air Operations Center 
TAR - Tactical Air Request 

TCO - Tactical Combat Operations 
IDS - Tactical Data Systems 

TIDP - Tactical Interface Design Plan 


USMC - United States Marine Corps 
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APPENDIX C: DASC INFORMATION REQUIREMENTS 
This appendix exhibits current DASC information requirements pertaining to the 
ATO database application. The messages, forms, and reports included are: 
e the message text format Air Tasking Order 
e the Joint Tactical Airstrike Request 
+ the Report-In/Out Log 


- the Operational Summary Report 
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AIR TASKING ORDER 
l. General 
The Air Tasking Order/Confirmation message is computer readable and includes 
information based on the users needs. The message can include the following groups of 
information. If the group (set) 1s used the format is as follows: 
SET NAME/FIELD I/FIELD 2/.../FIELD N// 
e Mandantory sets and fields are underlined. A field is mandandory only if that set 
is mandantory. 
- Vetical lines with arrows show repeatable sets and nested segments. 


- Capital letters means enter as is. 


2. Message Map 


EXER/exercise name/additional identifier// 
OPER/operation name/plan orginator and number/option name/second option name// 


MSID/ATOCONF/orginator/message serial number/month/qualifier/quailfier serial 
number// 


REF/serial letter/(usmtf message short title) or (type of reference)/orginator/date- 
time group/(msg ser number) or (doc ser number)/special notation/(sic) or (filing 


number)// 
AMPN/free text to explain preceeding reference set// 


NARR/free text to explain preceeding reference set// 


CANX/serial letter/(usmtf message short title) or (type of reference /orginator/date- 
time _group/(msg ser number) or (doc ser number)/special notation/(sic) or (filing 


number)// 

PERID/time from/TO: time to/ASOF: as of time// 
AIRTASK/air tasking/air tasking comments// 
TASKUNIT/tasked unit designator/ICAO location/comments// 
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MSNDATA/mission number/package identification/aircraft call sign/number and 
type of aircraft/mission type/alert status/primary configuration code/secondary 
configuration code/iff-sif code and mode// 


MSNLOC/mission__ start day-time/mission _ stop _day-time/mission location 
name/(altitude) or (flight level)/air support request number/area coordinates// 


TGTLOC/day-time on target/day-time off target/target identifier/target type/desired 


mean point of impact/air support request number/target comments// 


RECDATA/request _number/mission __priority/day-time on  target/latest time 


information of _value/reconnaissance mission _type/coverage type/imagery 
type/imagery code/coverage:mode/TGTCOD: reconnaissance target code/print 
scale/delivery address// 


TRCPLOT/location of initial point/trace point location// 


CONTROL/type_of control/callsign/(primary frequency) or (primary frequency 
designator)/(secondary frequency) or secondary frquency designator)/report-in 
point/control comments// 


FACINFO/callsign/(primary frequency) or (primary frequency 
designator)/(secondary frequency) or secondary frquency designator)/report-in 
point/support unit identity/control comments// 


ELECMBT/aircraft callsign/priority/mission location/(altitude) or (flight level)/time 
on station/time off station/primary (frequency) or frequency designator/secondary 
(frequency) or frequency designator// 


REFUEL/tanker call sign/tanker mission number/air refueling control point/(altitude) 
or (flight level)/air refueling control time/total offload of fuel/primary (frequency) 
or frequency designator/secondary (frequency) or frequency designator// 

7REFUEL/mission number/aircraft call sign/number and type aircraft/total offload 


of fuel/air refueling control time/tanker assignment/refueling fuel type/reciever 
comments/ 


AKNLDG/acknowledgement instructions// 
DECL/downgrading instructions// 
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JOINT TACTICAL AIRSTRIKE REQUEST 


JOINT TACTICAL AIRSTRIKE REQUEST Seet, for instructio 


SECTION 1- MISSION REOUEST DATE 


SENT 


1. UNIT CALLED THIS IS REQUEST NUMBER 


TIME BY 


RECEIVED 


PREPLANNED. [A] PRECEDENCE PRIORITY 
TIME BY 


IMMEDIATE: PRIORITY 





3. TARGET ISNNO OF 























[A] PERS IN OPEN ———— (B) PERS DUG in——— (E) WPNSIMGIARAT WU (0) MORTARS, AATY 

E) aaa aona (F) AKTS MISSILE G] ARMOR H) VEHICLES | 
{1} BLOGs BRIOGES [K] PILLBOX, BUNKERS —— [L] SUPPLIES, EOUIP 

[M] CENTER (CP, COM) [N] AREA [0] ROUTE (P] MOVING N E S W 

(0) REMARKS 





4 TARGET LOCATION IS 







CHECKED 


BY 








AA AA BI O] EE 
(COORDINATES) (COORDINATES) (COORDINATES) (COORDINATES) 


F) SHEET NO. (G] SERIES — 












[E] TGT ELEV [H] CHART NO 






5. TARGET TIMEIDATE 
[A] ASAP 


& DESIRED ORCYRESULTS 
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DESTROY NEUTRALIZE (D) HARASSINTERDICT 










7. FINAL CONTROL 
[A] FACIRABFAC 


(0] asar 


8. REMARKS 





CALL SIGN 
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(E) FLUCONT PT 
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SECTION 11 - COORDINATION 


Js CS 


12. REQUEST 13. BY 14. REASON FOR DISAPPROVAL 
[[] APPROVED 
(_) DISAPPROVED 














16. IS IN EFFECT 
D (FROM TIME) 


18. WIDTH 
(METERS) 








15. RESTRICTIVE FIRE/AIR PLAN 


[A] ¡iS NOT. 





(TO TIME) 
19. ALTITUDE/VERTEX 
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APPENDIX D: ENTITY-RELATIONSHIP SPECIFICATIONS 
This appendix lists and explains the information depicted on the Entity-Relationship 
diagram, Figure 8. It includes: 
e attribute names, abbreviations, formats, and keys 
e entities and relationship attribute listing 


e cardinality connections and rules 
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ENTITY-RELATIONSHIP ATTRIBUTES 


Attribute Name Abbreviation Format Key Abbrev 

A/C CALLSIGN C/S Eet Y ATO MSN 
X REFULEE 

Comm: A/C callsign 

OA TUAL TIME OF . ARRIVAL ATA N,4 N RIO LOGS 

Comm: Actual time A/C reported in with DASC 

ACTUAL TIME OF RETURN ATR N,4 N RIO LOGS 

Comm: Actual time A/C reported out with DASC 

AIRCRAFT TYPE TYPE Se H ATO MSN 
N REFULEE 


Comm: Aircraft/helicopter type/model/category (entry list 513) 


AIR TASKING CODE ATO CODE CC, 43 Y ATO 
Comm: Code for air tasking type (entry list 2005) 


ALERT STATUS ALR CS N ATO MSN 
Comm: Alert status code (Annex 33 CH 3/USMTF) 


ALTITUDE ALT C,5 N MSNLOC 
Comm: A/C altitude (Annex 2 CH 3/USMTF) 


AMOUNT OF FUEL LBSFUEL N, 4 N REFULEE 
Comm: Amount of fuel allowed per aircraft in hundreds of lbs 


ZERTIVAL TIME ATIME Cc. 7 N ROUTE 
Comm: Arrival time (Annex 2 CH 3/USMTF) 


ATO START ATO START Cr Y ATO 
Comm:Day, hour, minute, time zone of ATO Start 


ATO STOP ATO STOP Cl X ATO 
Comm: Day, hour, minute, time zone of ATO stop 


BDA COMMENT BDACMNT ESO N BDA 
Comm: Description of results 


CALLSIGN CALLSIGN E 15 Y CONTROL 
Comm: Control agency's callsign 


dE 


CONTROL AGENCY 
Comm: Code for the 


CONT ea N 


CONTROL POINT 
Comm: Location the 


RIO CP ce N 
A/C is to check an with the control 


CONTROL POINT TYPE 
Comm: Code for the 


CPTYP C 3 H 


COVERAGE TYPE COVERAGE Cpa N 
Comm: Code for type of coverage (Annex 34 CH 3/USMTF) 


CONTROL 


control agency type from the event list 


CONTROL 
agency 


ROUTE 


route point type (Annex 2 CH 3/USMTF) 


RECDATA 


EST TIME AIRBORNE ETA N,4 N A/C_STATUS 
Comm: Estimated time A/C airborne 
EST TIME OF RETURN ETR N,4 N A/C_ STATUS 
Comm: Estime time A/C returns 
FUEL REQUIREMENTS FUREQ N,4 N REFULEE 
Comm: Total amount of fuel req for the msn in hundreds of lbs 
IFE/ SIFE CODES IFFCODE Ce N ATO MSN 
Comm: IFF/SIF mode and code (1x (mode), 2-4N (code)) 
IMMEDIATE AIR REQUEST NUMBER IMMEDIATE C,5 xX IMED AIR 
Comm: JTAR, ASR, MEDEVAC Request Number 
LATEST TIME INFO OF VALUE LTIOV Gl] N RECDATA 
Comm: Latest time in year, month, day, hour, min, time zone 
LOCATION LOCN C,20 Y BDA 
N MSNLOC 
Y RECTGT 
N ROUTE 
N TGTLOC 
Comm: Mission location (entry list Il) 
LOCATION TYPE LOCTYP C76 N MSNLOC 
Comm: Code for a mission location (Annex 2 CH 3/USMTE) 
MISSION COMMENT MSNCMNT Grae N MSNLOC 
Comm: Comments on the mission location 
MISSION NUMBER MSNNO C: 8 Y ATO MSN 
X REFULEE 
Y RIO LOGS 
Comm: Mission No. (date, fixed/helo, sequence (25H-0009)) 
MISSION START MSTART el N RECDATA 


Comm: Time on target 
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MiS > TON. TYPE MSN Cz N ATO MSN 
N RECDATA 

Comm: Mission type (entry list 107A) 

NUMBER OF AIRCRAFT NO e3 N REFULEE 
N ATO MSN 

Comm: Number of aircraft 

PERCENT ORDNANCE ON TARGET ORD ON TGT  N,2 N BDA 

Comm: Percentage of Ordnance hitting target 

PERCENT TARGET DESTROYED TGT DESTROYED 211,2 N BDA 

Comm: Percentage of target destroyed 

POINT NUMBER PN N; 2 d ROUTE 


Comm: Numeric sequence given to the reference point (1-99) 


PRIMARY CONFIGURATION CODE PRICONFIG Ces N ATO MSN 
Comm: Primary configuration code for the aircraft 


PRIMARY FREQUENCY PRIFREQ €78 N CONTROL 
Comm: Frequency in megahertz, or the frequency designator (blue) 
SLOT Y PR El N RECDATA 
Comm: Priority for the mission 
EERDELING TIME RFLTIME EG N REFULEE 
Comm: Refueling time in day, hour, minute, time zone 
REQUEST NUMBER REQNO C76 Y MSNLOC 

Y RECDATA 


Comm: Preplanned Air Support Request Number 


SECONDARY CONFIGURATION CODE SECCONFIG C,5 N ATO MSN 
Comm: Secondary configuration code for the aircraft 


SECONDARY FREQUENCY SECFRQ Cr 8 N CONTROL 
Comm: Frequency in megahertz, or by frequency designator (blue) 


TARGET COMMENTS TGTCMNT C739 N TGTLOC 
Comm: Comments describing the target 


TERCET IDENTIFIER TGTID AD xX TGTLOC 
Comm: Assigned Target Number or Name (entry list Il, table II) 


TARGET LENGTH TLGTH et N RECTGT 
Comm: Estimated target length (Annex 2 CH 3/USMTF) 


MERGETI TYPE TGTTYP C76 N TGTLOC 
Comm: Target type (entry list 20) 


Fe 


TARGET WIDIH TWDRAD C N 
Comm: Estimated width or radius (Annex 2 CH 3/USMTF) 


TIME-OFF-TARGET TFT | T 
Comm: Time off target (day, hour, minute, time zone) 
TIME-OFF-TARGET TFT Gal N 
Comm: Time off target (day, hour, minute, time zone) 
TIME-ON-TARGET TOT Gn] Y 

N 
Comm: Time on target (day, hour, minute, time zone) 
UNIT SUPPORTED SUPPORTED C79 N 

N 


Comm: Unit supported by Immediate Air Request 
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RECTGT 


BDA 


TGTLOC 


BDA 
TGTLOC 


IMED AIR 
BDA 


ENTITY AND RELATIONSHIP REPORT 


AIR_TASKING_ORDER Relation Type - Entity 
List of Attributes (fields): 
Name Abbreviation Format Key 
1. ATO_START ATO_START C,7 Y 
Day, hour, minute, time zone of ATO Start 
2. ATO_STOP ATO_STOP C7 Y 
Day, hour, minute, time zone of ATO stop 
3. AIR_TASKING_CODE ATO_CODE C,43 Y 


Code for air tasking type (entry list 2005) 


ASSESSES Relation Type - Relationship 
Remark: BDAs may be reported on a target 
List of Attnbutes (fields): NONE 


BATTLE_DAMAGE_ASSESSMENT Relation Type - Entity 

List of Attributes (fields): 
Name Abbreviation Format Key 

1. LOCATION LOCN C,20 Y 
Mission location (entry list 11) 

2. TIME-ON-TARGET TOT C7 Y 
Time on target (day, hour, minute, time zone) 

3. TIME-OFF-TARGET TFI e7 Y 
Time off target (day, hour, minute, time zone) 

4. PERCENT_ORDNANCE_ON_TARGET ORD_ON_TGT N,2 N 
Percentage of Ordnance hitting target 

5. PERCENT_TARGET_DESTROYED TGT_DESTROYED N,2 N 
Percentage of target destroyed 

6. BDA_COMMENT BDACMNT C,30 N 
Description of results 

7. UNIT_SUPPORTED SUPPORTED C,9 N 

COMPRISES Relation Type - Relationship 


Remark: ATO is comprised of various missions 
List of Attributes (fields): NONE 


CONTROLS Relation Type - Relationship 
Remark: A/C Mission is controlled by various controlling agencies 
List of Attributes (fields): NONE 


SES 


CONTROL_AGENCY Relation Type - Entity 
List of Attributes (fields): 


Name Abbreviation Format 
1. CALLSIGN CALLSIGN e35 
Control agency’s callsign 
2. CONTROL_AGENCY CONT C,4 
Code for the control agency type from the event list 
3. PRIMARY_FREQUENCY PRIFREQ C8 
Frequency in megahertz, or the frequency designator (blue) 
4. SECONDAR Y_FREQUENCY SECFRQ C8 
Frequency in megahertz, or by frequency designator (blue) 
5. CONTROL_POINT RIO_CP C,20 
Location the A/C is to check in with the control agency 
IMMEDIATE_REQUESTS Relation Type - Entity 
List of Attributes (fields): 
Name Abbreviation Format 
I. IMMEDIATE AIR REQUEST NUMBER IMMEDIATE ED 
JTAR, ASR, MEDEVAC Request Number 
2. UNIT_SUPPORTED SUPPORTED 59 
Unit supported by Immediate Air Request 
INTEREST_IN Relation Type - Relationship 


Remark: Recon MSN interested in Recon Target Data 
List of Attributes (fields): NONE 


MAY_DESIGNATE Relation Type - Relationship 


Remark: Entity Route if the Mission is to follow a certain route 
List of Attributes (fields): NONE 
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Key 


MISSION (ATO MISSION) Relation Type - Entity 
List of Attributes (fields): 


Name Abbreviation Format Key 

1. MISSION NUMBER MSNNO C8 ¥ 
Mission No. (date. fixed/helo, sequence (25H-0009)) 

2. A/CCALLSIGN C/S C2 Y 
A/C callsign 

3. NUMBER_OF_AIRCRAFT NO C2 N 
Number of Aircraft 

4. AIRCRAFI_TYPE kt HE C,6 N 
Aircraft/helicopter type/model/category (entry list 513) 

5. MISSION_TYPE MSN C3 N 
Mission type (entry list 107A) 

6. ALERT_STATUS ALR C3 N 
Alert status code (Annex 33 CH 3/USMTF) 

7. PRIMARY_CONFIGURATION_CODE PRICONFIG C5 N 
Primary configuration code for the aircraft 

8. SECONDARY_CONFIGURATION_CODE SECCONFIG es N 
Secondary configuration code for the aircraft 

9. IFF/SIF_CODES IFFCODE es N 
IFF/SIF mode and code (1x (mode), 2-4N (code)) 

10. EST_TIME_AIRBORNE ETA N,4 N 
Estimated time A/C airborne 

11. EST_TIME_OF_RETURN ETR N,4 N 
Estimated time A/C returns 

MISSION_LOCATION Relation Type- Entity 
List of Attributes (fields): 

Name Abbreviation Format Key 

1. REQUEST_NUMBER REQNO C,6 Y 
Preplanned Air Support Request Number 

2. LOCATION_TYPE LOCTYP C,6 N 
Code for a mission location (Annex 2 CH 3/USMTF) 

3. LOCATION LOCN C,20 N 
Mission location (entry list 11) 

4. ALTITUDE ALT es N 
A/C altitude (Annex 2 CH 3/USMTF) 

5. MISSION _COMMENT MSNCMNT C22 N 


Comments on the mission location 
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RECEIVING_AIRCRAFT Relation Type - Entity 
List of Attributes (fields): 


Name Abbreviation Format Key 

1. MISSION_NUMBER MSNNO C8 Y 
Mission No. (date, fixed/helo, sequence (25H-0009)) 

2. A/CCALLSIGN C/S CD X 
A/C callsign 

3. NUMBER_OF_AIRCRAFT NO Ore N 
Number of aircraft 

4, AIRCRAFT TYPE TYPE C,6 N 
Aircraft/helicopter type/model/category (entry list 513) 

5. AMOUNT_OF_ FUEL LBSFUEL N,4 N 
Amount of fuel allowed per aircraft in hundreds of Ibs 

6. FUEL_REQUIREMENTS FUREQ N,4 N 
Total amount of fuel req for the msn in hundreds of Ibs 

7. REFUELING_TIME RFLTIME CY N 


Refueling time in day, hour, minute, time zone 


RECONNAISSANCE Relation Type - Entity 
List of Attributes (fields): 
Name Abbreviation Format Key 

1. REQUEST NUMBER REQNO 6 Y 
Preplanned Air Support Request Number 

2. PRIORITY PR el N 
Priority for the mission 

3. MISSION_START MSTART C7 N 
Time on target 

4. LATEST TIME _INFO_ OF VALUE LTIOV CH N 
Latest time in year, month, day, hour, min, time zone 

5. MISSION_TYPE MSN Cs N 
Mission type (entry list 107A) 

6. COVERAGE_TYPE COVERAGE C,7 N 


Code for type of coverage (Annex 34 CH 3/USMTF) 


RECON_TARGET Relation Type - Entity 
List of Attributes (fields): 
Name Abbreviation Format Key 
1. LOCATION LOCN C20 Y 
Mission location (entry list 11) 
2. TARGET_LENGTH TLGTH C7 N 
Estimated target length (Annex 2 CH 3/USMTF) 
3. TARGET_WIDTH TWDRAD C,7 N 


Estimated width or radius (Annex 2 CH 3/USMTF) 


REFUELS Relation Type - Relationship 
Remark: Refueling Mission Refuels Receiving Aircraft 
List of Attributes (fields): NONE 
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REQUESTS Relation Type - Relationship 


Remark: Immediate air support requests Mission from ATO to perform List of Attributes (fields): 


NONE 
RIO_LOGS Relation Type - Entity 
List of Attributes (fields): 
Name Abbreviation Format Key 

1. MISSION_NUMBER MSNNO C,8 

Mission No. (date, fixed/helo, sequence (25H-0009)) 
2. ACTUAL_TIME_OF_ARRIVAL ATA N,4 

Actual time A/C reported in with DASC 
3. ACTUAL_TIME_OF_RETURN ATR N,4 


Actual time A/C reported out with DASC 


ROUTE Relation Type - Entity 
List of Attributes (fields): 
Name Abbreviation Format Key 
1. POINT_NUMBER PN N,2 
Numeric sequence given to the reference point (1-99) 
2. CONTROL_POINT_TYPE CETYP ES 
Code for the route point type (Annex 2 CH 3/USMTF) 
3. LOCATION LOCN C,20 
Mission location (entry list 11) 
4. ARRIVAL_TIME ATIME C7 


Arrival time (Annex 2 CH 3/USMTF) 


TARGET_LOCATION Relation Type - Entity 
List of Attributes (fields): 
Name Abbreviation Format Key 

I. TARGET_IDENTIFIER TGTID C,20 
Assigned Target Number or Name (entry list 11, table I) 

2. TIME-ON-TARGET TOT C7 
Time on target (day, hour, minute, time zone) 

3. TIME-OFF-TARGET TFT CF 
Time off target (day, hour, minute, time zone) 

4. TARGET_TYPE TGTTYB C,6 
Target type (entry list 20) 

5. LOCATION LOCN C,20 
Mission location (entry list Il) 

6. TARGET_COMMENTS TGTCMNT 635 


Comments describing the target 


UPDATES Relation Type - Relationship 
Remark: TAD/HD logs append/update ATO with actual data List 
List of Attributes (fields): NONE 
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CARDINALITY and CELL LINKS REPORT 


Connections Listing by Cell 


Entity AIR_TASKING_ORDER abbrev: 
to Entity MISSION abbrev: 
through Relationship COMPRISES abbrev: 
CARDINALITY CARDINALITY 

lower = | lower = | 

upper = 1 upper = N 

lowern = | lower n= | 

upper n = | upper n = 

Entity AIR_TASKING_ORDER abbrev: 
to Entity RIO_LOGS abbrev: 
through Relationship UPDATES abbrev: 
CARDINALITY CARDINALITY 

lower = | lower = | 

upper = | upper = N 

lower n= 1 lower n = 1 

upper n = 1 upper n = 

Entity MISSION abbrev: 
to Entity IMMEDIATE_REQUESTS abbrev: 
through Relationship REQUESTS abbrev: 
CARDINALITY CARDINALITY 

lower = | lower = 0 

upper = N upper = N 

lower n = | lower n = 0 

upper n = upper n = 
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ATO 
ATO_MSN 
COMP 


ATO 
RIO_LOGS 
UPDATES 


ATO MSN 
IMED AIR 
REQUESTS 


Entity MISSION 
parent of Entity RECONNAISSANCE 


abbrev: ATO MSN 
abbrev: RECDATA 


through ISA RELATIONSHIP MISSION abbrev: ATO MSN 


CARDINALITY 
lower = ] 

upper = 1 

lower n= 1 
upper n= 1 


Entity MISSION 
parent of Entity MISSION_LOCATION 


CARDINALITY 
lower = 0 

upper = N 
lower n = 0 
upper n = 


abbrev: ATO MSN 
abbrev: MSNLOC 


through ISA RELATIONSHIP MISSION abbrev: ATO MSN 


CARDINALITY 
lower = 1 

upper = | 

lower n = 1 
upper n = Î 


Entity MISSION 
to Entity AIR TASKING_ ORDER 
through Relationship COMPRISES 


CARDINALITY 
lower = 1 

upper = N 
lower n = 1 
upper n = 


Entity MISSION 
to Entity ROUTE 
through Relationship MAY_DESIGNATE 


CARDINALITY 
lower = 1 

upper = 1 

lower n = 1 
upper n = 1 


CARDINALITY 
lower = 0 

upper = N 
lower n = 0 
upper n = 


abbrev: ATO_MSN 
abbrev: ATO 
abbrev: COMP 


CARDINALITY 
lower = 1 

upper = 1 

lower n = 1 
upper n = 1 


abbrev: ATO_MSN 
abbrev: ROUTE 
abbrev: DESIGNAT 


CARDINALITY 
lower = 0 

upper = N 
lower n = 0 
upper n = 
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Entity MISSION abbrev: ATO MSN 
parent of Entity TARGET LOCATION  abbrev: TGTLOC 
through ISA RELATIONSHIP MISSION abbrev: ATO MSN 


CARDINALITY CARDINALITY 

lower = 1 lower = 0 

upper = 1 upper = N 

lower n = 1 lower n= 0 

upper n = 1 upper n = 

Entity MISSION abbrev: ATO_MSN 
to Entity CONTROL_AGENCY abbrev: CONTROL 
through Relationship CONTROLS abbrev: CONTROLS 
CARDINALITY CARDINALITY 

lower = 1 lower = 0 

upper = 1 upper = N 

lower n = 1 lower n = 0 

upper n= | upper n = 


Entity BATTLE_DAMAGE_ ASSESSMENT abbrev: BDA 


to Entity TARGET_LOCATION abbrev: TGTLOC 
through Relationship ASSESSES abbrev: ASSESSES 
CARDINALITY CARDINALITY 

lower = 0 lower = I 

upper = N upper = | 

lower n = 0 lower n = 1 

upper n = upper n = I 

Entity CONTROL_AGENCY abbrev: CONTROL 
to Entity MISSION abbrev: ATO_MSN 
through Relationship CONTROLS abbrev: CONTROLS 
CARDINALITY CARDINALITY 

lower = 0 lower = 1 

upper = N upper = | 

lower n = 0 lower n = 1 

upper n = upper n = | 
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Entity IMMEDIATE_REQUESTS abbrev: IMED AIR 


to Entity MISSION abbrev: ATO_ MSN 
through Relationship REQUESTS abbrev: REQUESTS 
CARDINALITY CARDINALITY 

lower = 0 lower = 1 

upper = N upper = N 

lower n = 0 lower n = | 

upper n = upper n = 

Entity MISSION_LOCATION abbrev: MSNLOC 
to Entity RECEIVING_AIRCRAFT abbrev: REFULEE 
through Relationship REFUELS abbrev: REFUELS 
CARDINALITY CARDINALITY 

lower = 1 lower = 0 

upper = 1 upper = N 

lower n = 1 lower n = 0 

upper n = 1 upper n = 

Entity MISSION_LOCATION abbrev: MSNLOC 
child of Entity MISSION abbrev: ATO_MSN 
through ISA RELATIONSHIP MISSION abbrev: ATO_MSN 
CARDINALITY CARDINALITY 

lower = 0 lower = 1 

upper = N upper = 1 

lower n = 0 lower n = 1 

upper n = upper n= 1 

Entity RECONNAISSANCE abbrev: RECDATA 

to Entity RECON_TARGET abbrev: RECTGT 
through Relationship INTEREST_IN abbrev: INT 
CARDINALITY CARDINALITY 

lower = 1 lower = 1 

upper = N upper = N 

lower n = 1 lower n = 1 

upper n = upper n = 
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Entity RECONNAISSANCE 
child of Entity MISSION 
through ISA RELATIONSHIP MISSION 


CARDINALITY CARDINALITY 

lower = 0 lower = 1 

upper = N upper = 1 

lower n = 0 lower n = 1 

upper n = upper n= 1 

Entity RECON TARGET abbrev: 
to Entity RECONNAISSANCE abbrev: 
through Relationship INTEREST_IN abbrev: 
CARDINALITY CARDINALITY 

lower = | lower = J 

upper = N upper = N 

lower n= 1 lower n = 1 

upper n = upper n = 

Entity RECEIVING_AIRCRAFT abbrev: 
to Entity MISSION_LOCATION abbrev: 
through Relationship REFUELS abbrev: 
CARDINALITY CARDINALITY 

lower = 0 lower = 1 

upper = N upper = 1 

lower n = 0 lower n = 1 

upper n = upper n = | 

Entity RIOLOGS abbrev: 
to Entity AIR_TASKING_ORDER abbrev: 
through Relationship UPDATES abbrev: 
CARDINALITY CARDINALITY 

lower = | lower = 1 

upper = N upper = 1 

lower n= 1 lower n = 1 

upper n = upper n = 1 
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abbrev: RECDATA 
abbrev: 
abbrev: ATO_MSN 


ATO MSN 


RECTGT 
RECDATA 
INT 


REFULEE 
MSNLOC 
REFUELS 


RIO_LOGS 
ATO 
UPDATES 


Entity ROUTE abbrev: ROUTE 
to Entity MISSION abbrev: ATO MSN 
through Relationship MAY _DESIGNATE abbrev: DESIGNAT 


CARDINALITY CARDINALITY 

lower = 0 lower = | 

upper = N upper = | 

lower n = 0 lower n = 1 

upper n = upper n = | 

Entity TARGET_LOCATION abbrev: TGTLOC 
child of Entity MISSION abbrev: ATO_MSN 
through ISA RELATIONSHIP MISSION abbrev: ATO_MSN 
CARDINALITY CARDINALITY 

lower = 0 lower = | 

upper = N upper = | 

lower n = 0 lower n = 1 

upper n = upper n = 1 

Entity TARGET_LOCATION abbrev: TGTLOC 
to Entity BATTLE_DAMAGE_ASSESSMENT abbrev: BDA 
through Relationship ASSESSES abbrev: ASSESSES 
CARDINALITY CARDINALITY 

lower = | lower = 0 

upper = 1 upper = N 

lowern= | lower n = 0 

upper n= | upper n = 

ISA RELATIONSHIP MISSION’s abbrev: ATO_MSN 
parent is Entity MISSION abbrev: ATO_MSN 
ISA RELATIONSHIP MISSION’s abbrev: ATO_MSN 


child is Entity TARGET_LOCATION abbrev: TGTLOC 


ISA RELATIONSHIP MISSION’s abbrev: ATO_MSN 
child is Entity MISSION _LOCATION abbrev: MSNLOC 
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ISA RELATIONSHIP MISSION’s 
parent ıs Entity MISSION 


ISA RELATIONSHIP MISSION’s 
child is Entity RECONNAISSANCE 


ISA RELATIONSHIP MISSION’s 
parent is Entity MISSION 


Relationship ASSESSES 
to Entity TARGET_LOCATION 


CARDINALITY 
lower = | 

upper = 1 

lower n = 1 
upper n= 1 


Relationship ASSESSES 


abbrev: 
abbrev: 


abbrev: 
abbrev: 


abbrev: 
abbrev: 


abbrev: 
abbrev: 


abbrev: 


ATO_MSN 
ATO_MSN 


ATO_MSN 
RECDATA 


ATO_MSN 
ATO_MSN 


ASSESSES 
TGTLOC 


ASSESSES 


to Entity BATTLE_DAMAGE_ASSESSMENT abbrev: BDA 


CARDINALITY 
lower = 0 

upper = N 
lower n = 0 
upper n = 


Relationship COMPRISES 
to Entity AIR_TASKING_ORDER 


CARDINALITY 
lower = 1 

upper = 1 

lower n = 1 
upper n = | 


abbrev: 
abbrev: 
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COMP 
ATO 


Relationship COMPRISES 
to Entity MISSION 


CARDINALITY 
lower = | 

upper = N 
lower n = | 
upper n = 


Relationship CONTROLS 
to Entity MISSION 


CARDINALITY 
lower = | 

upper = | 

lower n = | 
upper n = | 


Relationship CONTROLS 
to Entity CONTROL _ AGENCY 


CARDINALITY 
lower = 0 

upper = N 
lower n = 0 
upper n = 


Relationship MAY-DESIGNATE 
to Entity MISSION 


CARDINALITY 
lower = 1 

upper = | 

lower n= | 
upper n = 1 


abbrev: COMP 
abbrev: ATO_MSN 


abbrev: CONTROLS 
abbrev: ATO_MSN 


abbrev: CONTROLS 
abbrev: CONTROL 


abbrev: DESIGNAT 
abbrev: ATO_MSN 
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Relationship MAY _DESIGNATE 


to Entity ROUTE 


CARDINALITY 
lower = 0 

upper = N 
lower n = 0 
upper n = 


Relationship INTEREST_IN 
to Entity RECON_TARGET 


CARDINALITY 
lower = | 

upper = N 
lowern=| 
upper n = 


Relationship INTEREST_IN 
to Entity RECONNAISSANCE 


CARDINALITY 
lower = 1 

upper = N 
lower n = 1 
upper n = 


Relationship REFUELS 


to Entity RECEIVING_AIRCRAFT 


CARDINALITY 
lower = 0 

upper = N 
lower n = 0 
upper n = 


abbrev: DESIGNAT 
abbrev: ROUTE 


abbrev: INT 
abbrev: RECTGT 


abbrev: INT 
abbrev: RECDATA 


abbrev: REFUELS 
abbrev: REFULEE 
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Relationship REFUELS 
to Entity MISSION_LOCATION 


CARDINALITY 
lower = 1 

upper = 1 

lower n = 1 
upper n = 1 


Relationship REQUESTS 
to Entity IMMEDIATE_REQUESTS 


CARDINALITY 
lower = 0 

upper = N 
lower n = 0 
upper n = 


Relationship REQUESTS 
to Entity MISSION 


CARDINALITY 
lower = 1 

upper = N 
lower n = 1 
upper n = 


Relationship UPDATES 
to Entity AIR_TASKING_ORDER 


CARDINALITY 
lower = 1 

upper = 1 

lower n = 1 
upper n = 1 


abbrev: REFUELS 
abbrev: MSNLOC 


abbrev: REQUESTS 
abbrev: IMED AIR 


abbrev: REQUESTS 
abbrev: ATO_MSN 


abbrev: UPDATES 
abbrev: ATO 


>] 


Relationship UPDATES abbrev: UPDATES 
to Entity RIO_LOGS abbrev: RIO_LOGS 


CARDINALITY 
lower = 1 

upper = N 
lower n= 1 
upper n = 
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APPENDIX E: E-R DESIGNER RELATIONAL SCHEMA 
CONTROL_AGENCY (callsign : control_agency, primary_frequency, secondary_frequency, 
control_point) 

AIR_TASKING_ORDER (ato start, ato stop, air tasking code :) 
ROUTE (mission number, point number : control_point_type, location, arrival_time) 
RIO_LOGS (mission number : actual_time_of_arrival, actual_time_of_ return) 


RECEIVING_AIRCRAFT (mussion number, alc callsign : number_of_aircraft, aircraft_type, 
amount_of_fuel, fuel_requirements, refueling_time) 


BATTLE DAMAGE_ ASSESSMENT (location, time-on-target : time-off-target, 
percent_ordnance_on_target, percent_target_destroyed, bda_comment, unit_supported) 


MISSION_LOCATION (request number, mission number, alc_callsign : location_type, 
location, altitude, mission_comment) 


MISSION (mission number, alc callsign, request number : number_of_aircraft, aircraft_type, 
mission_type, alert_status, primary_configuration_code, secondary_configuration_code, 


iff/sif_codes, est_time_airbome, est_time_of_retum) 


TARGET_LOCATION (target_identifier, mission_number, alc_callsign, request_number : 
time-on-target, tume-off-target, target_type, location, target_comments) 


RECONNAISSANCE (request number : priority, mission_ start, mission_stop, 
latest_time_info_of value, mission_type, coverage type) 


IMMEDIATE_REQUESTS (immediate air request number : unit_supported) 


RECON_TARGET (location : target_length, target_width) 


RELATION (primary key attribute(s) : non-key attribute(s)) 
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COMPRISES (ato start, ato stop, air tasking code, mission number, a/c_callsign :) 
ASSESSES (target identifier, location, time-on-target, time-off-target :) 
CONTROLS (mission number, alc callsign, callsign :) 

REQUESTS (immediate air request number, mission number, alc callsign :) 
INTEREST_IN (location, request number :) 

MAY_DESIGNATE (mission number, alc callsign, point number :) 

UPDATES (aro start, ato stop, air tasking code, mission number :) 


REFUELS Gission number, alc callsign, request number :) 
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E-R Designer Relational Schema File Format 


CONTROL_AGENCY 5 1 


CALLSIGN C15 
CONTROL_AGENCY C4 
PRIMAR Y_ FREQUENCY C,8 
SECONDARY_FREQUENCY C,8 
CONTROL_POINT C20 
AIR_TASKING_ORDER 3 3 
ATO_START C7 
ATO_STOP C7 
AIR_TASKING_CODE C,43 
ROUTE 5 2 
MISSION_NUMBER C,8 
POINT_NUMBER NE? 
CONTROL_ POINT _ TYPE ES 
LOCATION 20 
ARRIVAL_TIME C7 
RIO TOGS 3 1 
MISSION_NUMBER es 
ACTUAL_TIME_OF_ARRIVAL N,4 
ACTUAL_TIME_OF_RETURN N,4 
RECEIVING_AIRCRAFT 7 2 
MISSION_NUMBER Cs 
A/C_CALLSIGN 2412 
NUMBER_OF_AIRCRAFT REZ 
AIRCRAFT_ TYPE 5 
AMOUNT_OF_FUEL N,4 
FUEL_REQUIREMENTS N,4 
REFUELING_TIME C 
---------------------- Key---------------------------------------- 
Relation # of attributes, # of primary key attributes 
Attribute field format, max length 


C (character) 
N (numeric) 
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BATTLE_DAMAGE_ASSESSMENT 7 3 
LOCATION 
TIME-ON-TARGET 
TIME-OFF-TARGET 
PERCENT_ORDNANCE_ON_TARGET 
PERCENT_TARGET_DESTROYED 
BDA_COMMENT 
UNIT_SUPPORTED 


MISSION_LOCATION 7 3 
REQUEST_NUMBER 
MISSION_NUMBER 
A/C_CALLSIGN 
LOCATION_TYPE 
LOCATION 
ALTITUDE 
MISSION_ COMMENT 


MISSION 13 3 
MISSION_ NUMBER 
A/C_CALLSIGN 
REQUEST NUMBER 
NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE 
MISSION_TYPE 
ALERT_STATUS 
PRIMARY_CONFIGURATION_CODE 


SECONDAR Y_CONFIGURATION_CODE 


IFF/SIF_CODES 
EST_TIME_AIRBORNE 
EST_TIME_OF_RETURN 


TARGET_LOCATION 9 4 
TARGET_IDENTIFIER 
MISSION_NUMBER 
A/C_CALLSIGN 
REQUEST_NUMBER 
TIME-ON-TARGET 
TIME-OFF-TARGET 
TARGET_TYPE 
LOCATION 
TARGET_COMMENTS 
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ey 
Cy 


N,2 
N,2 
ESO 
ey 


Co 
C,8 
12 
eu 
C,20 
C3 
EE 


L 3 
Cal2 
Co 
C,2 
C,6 
Es) 
C3 
es 
C5 
De 
N,4 
N,4 


C,20 
C,8 
CZ 
eo 
C,7 
67 
CO 
C0 
C235 


RECONNAISSANCE 7 1 
REQUEST NUMBER 
PRIORITY 
MISSION_ START 
MISSION_STOP 
LATEST TIME_INFO_OF_ VALUE 
MISSION_ TYPE 
COVERAGE TYPE 


IMMEDIATE_REQUESTS 2 1 
IMMEDIATE_AIR_REQUEST_NUMBER 
UNIT_SUPPORTED 


RECON_TARGET 3 1 
LOCATION 
TARGET_LENGTH 
TARGET_WIDTH 


COMPRISES 5 5 
ATO_START 
ATO_STOP 
AIR_TASKING_CODE 
MISSION_NUMBER 
A/C_CALLSIGN 


ASSESSES 4 4 
TARGET_IDENTIFIER 
LOCATION 
TIME-ON-TARGET 
TIME-OFF-TARGET 


CONTROLS 3 3 
MISSION_NUMBER 
A/C_CALLSIGN 
CALLSIGN 


REQUESTS 3 3 
IMMEDIATE_AIR_REQUEST_NUMBER 
MISSION_NUMBER 
A/C_CALLSIGN 
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C,6 
l 
er 
Cy 
Cli 
Ce» 
eZ 


C3 
ne 


C,20 


C7 


GF 
Cx 
C,43 
C8 
E12 


C20 
C,20 
EN 
C7 


C,8 
C1? 
CLS 


C5 
C8 
C12 


INTEREST_IN 2 2 
LOCATION 
REQUEST_NUMBER 


MAY _DESIGNATE 3 3 
MISSION_NUMBER 
A/C_CALLSIGN 
POINT_NUMBER 


UPDATES 4 4 
ATO_START 
ATO_STOP 
AIR_TASKING_CODE 
MISSION_NUMBER 


REFUELS 3 3 
MISSION_NUMBER 
A/C_CALLSIGN 
REQUEST_NUMBER 
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C20 
co 


C,8 
Cr? 
N,2 


E 
C 
C,43 
L 3 


E 
eZ 
C,6 


APPENDIX F: NORMALIZER LOG 


ENTERING FD FOR THE RELATION: CONTROL AGENCY 


CONTROL_AGENCY (CALLSIGN, CONTROL_AGENCY, PRIMARY_FREQUENCY, 
SECONDAR Y_ FREQUENCY, CONTROL_POINT) 


Candidate keys= 
1 CALLSIGN 


All Fd’s entered for this relation 

l: CALLSIGN ---> CONTROL_AGENCY PRIMARY FREQUENCY 
SECONDAR Y_ FREQUENCY 

2: CONTROL_AGENCY ---> CONTROL_POINT 


RESULT OF CHECKING NORMAL FORMS FOR RELATION (CONTROL_AGENCY) 


NOTATION: Y : SATISFACTORY N: NOT SATISFACTORY 
FD no. BCNF 3NF 


l O 
2 N N 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


CONSTRUCTION OF RELATIONS begins..... 

The relation (CONTROL_AGENCY) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation 1s decomposed to : 

(CALLSIGN : CONTROL_AGENCY, PRIMAR Y_FREQUENCY, 
SECONDARY_FREQUENCY) 

(CONTROL_AGENCY : CONTROL_POINT) 

Checking for LOSSLESS JOIN begins.... 


Decomposition is LOSSLESS 


>» 


The relations are SYNTHESIZED, 
FD-PRESERVING, LOSSLESS, and MINIMAL relations 


Now, ASSIGN the relation name for new relation(s). 
New Decomposed Relations: 
(CALLSIGN : CONTROL_AGENCY, PRIMARY_FREQUENCY, 
SECONDARY_FREQUENCY) 
Enter A new name for the relation above ===> 
New Decomposed Relations: 
(CONTROL_AGENCY : CONTROL_POINT) 
Enter A new name for the relation above ===> 


FDs after Nonnalization 

1. CALLSIGN ---> CONTROL_AGENCY PRIMARY _ FREQUENCY 
SECONDAR Y_FREQUENCY 

2. CONTROL_AGENCY ---> CONTROL_POINT 
ENTERING FD FOR THE RELATION: AIR TASKING ORDER 


AIR_TASKING_ORDER (ATO_START, ATO_STOP, AIR _TASKING CODE) 


ENTERING FD FOR THE RELATION: ROUTE 


ROUTE (MISSION_NUMBER, POINT_NUMBER, CONTROL_POINT_TYPE, LOCATION, 


ARRIVAL_TIME) 


ENTERING FD FOR THE RELATION: RIO_LOGS 

RIO_LOGS (MISSION_NUMBER, ACTUAL_TIME_OF_ARRIVAL, 
ACTUAL_TIME_OF_RETURN) 

ENTERING FD FOR THE RELATION: RECEIVING AIRCRAFT 
RECEIVING_AIRCRAFT (MISSION _NUMBER, A/C_CALLSIGN, 
NUMBER_OF_AIRCRAFT, AIRCRAFT_TYPE, AMOUNT_OF_FUEL, 
FUEL_REQUIREMENTS, REFUELING_TIME) 


Candidate keys= 
l MISSION_NUMBER A/C_CALLSIGN 
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All Fd’s entered for thıs relation 
1: MISSION_NUMBER A/C_CALLSIGN ---> NUMBER_OF_AIRCRAFT 
AIRCRAFT TYPE AMOUNT OF_FUEL REFUELING_ TIME 


2: NUMBER_OF_AIRCRAFT AMOUNT_OF_FUEL ---> FUEL_REQUIREMENTS 


RESULT OF CHECKING NORMAL FORMS FOR RELATION 
(RECEIVING_AIRCRAFT) 
NOTATION: Y : SATISFACTORY WN: NOT SATISFACTORY 
FD no. BCNF 3NF 


J DEN y 
2 N N 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


CONSTRUCTION OF RELATIONS begins..... 
The relation (RECEIVING_AIRCRAFT) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation is decomposed to : 

(MISSION_NUMBER, A/C_CALLSIGN : NUMBER_OF_AIRCRAFT, AIRCRAFT_TYPE, 

AMOUNT_OF_FUEL, REFUELING_TIME) 

(NUMBER_OF_AIRCRAFT, AMOUNT_OF_FUEL : FUEL_ REQUIREMENTS) 

Checking for LOSSLESS JOIN begins.... 


Decomposition is LOSSLESS 
The relations are SYNTHESIZED, 
FD-PRESERVING, LOSSLESS, and MINIMAL relations 


Now, ASSIGN the relation name for new relation(s). 
New Decomposed Relations: 
(MISSION_NUMBER, A/C_CALLSIGN : NUMBER_OF_AIRCRAFT, AIRCRAFI_TYPE, 
AMOUNT_OF_FUEL, REFUELING_TIME) 
Enter A new name for the relation above ===> 
New Decomposed Relations: 
(NUMBER_OF_AIRCRAFT, AMOUNT_OF_FUEL : FUEL_REQUIREMENTS) 
Enter À new name for the relation above === 
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FDs after Normalization 

1. MISSION_NUMBER A/C_CALLSIGN ---> NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE AMOUNT_OF_FUEL REFUELING_TIME 

2. NUMBER_OF_AIRCRAFT AMOUNT_OF_FUEL ---> FUEL_REQUIREMENTS 
ENTERING FD FOR THE RELATION: BATTLE DAMAGE ASSESSMENT 
BATTLE DAMAGE ASSESSMENT (LOCATION, TIME-ON-TARGET, 
TIME-OFF-TARGET, PERCENT ORDANANCE ON TARGET, 
PERCENT TARGET _DESTROYED, BDA COMMENT, UNIT_SUPPORTED) 
ENTERING FD FOR THE RELATION: MISSION LOCATION 


MISSION_LOCATION (MISSION_NUMBER, A/C_CALLSIGN, REQUEST _ NUMBER, 
LOCATION_TYPE, LOCATION, ALTITUDE, MISSION_COMMENT) 


Candidate keys= 
1 MISSION NUMBER A/C_CALLSIGN REQUEST_NUMBER 


All Fd’s entered for this relation 
1: REQUEST NUMBER ---> LOCATION TYPE LOCATION 


2: MISSION_NUMBER A/C_CALLSIGN REQUEST_ NUMBER ---> ALTITUDE 
MISSION_COMMENT 
RESULT OF CHECKING NORMAL FORMS FOR RELATION (MISSION_LOCATION) 


NOTATION: Y : SATISFACTORY N: NOT SATISFACTORY 
FD no. BCNF 3NF 


J N N 
2 oe 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


CONSTRUCTION OF RELATIONS begins..... 
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The relation (MISSION LOCATION) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation is decomposed to : 

(REQUEST_NUMBER : LOCATION_TYPE, LOCATION) 
(MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER : ALTITUDE, 
MISSION_COMMENT) 

Checking for LOSSLESS JOIN begins.... 


Decomposition is LOSSLESS 
The relations are SYNTHESIZED, 
FD-PRESERVING, LOSSLESS, and MINIMAL relations 


Now, ASSIGN the relation name for new relation(s). 
New Decomposed Relations: 
(REQUEST_NUMBER : LOCATION_TYPE, LOCATION) 
Enter A new name for the relation above ===> 
New Decomposed Relations: 
(MISSION _ NUMBER, A/C_CALELSIGN, REQUEST _ NUMBER : ALTITUDE, 
MISSION _ COMMENT) 
Enter A new name for the relation above ===> 


FDs after Normalization 

1. REQUEST_NUMBER ---> LOCATION_TYPE LOCATION 

2. MISSION_NUMBER A/C_CALLSIGN REQUEST_NUMBER ---> ALTITUDE 
MISSION_COMMENT 


ENTERING FD FOR THE RELATION: MISSION 


MISSION (MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER, 
NUMBER_OF_AIRCRAFT, AIRCRAFT_TYPE, MISSION_TYPE, ALERT_STATUS, 
PRIMAR Y_CONFIGURATION_CODE, SECONDARY_CONFIGURATION_CODE, 
IFF/SIF_CODES, EST_TIME_AIRBORNE, EST_TIME_OF_RETURN) 


Candidate keys= 
1 MISSION_NUMBER A/C_CALLSIGN REQUEST_NUMBER 


All Fd’s entered for this relation 

1: MISSION_NUMBER A/C_CALESIGN ---> NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE MISSION_TYPE ALERT_STATUS 
PRIMARY _CONFIGURATION_CODE SECONDARY CONFIGURATION _CODE 
IFF/SIF CODES 


2: A/C_CALLSIGN ---> NUMBER_OF_AIRCRAFT AIRCRAFT TYPE 
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3: MISSION NUMBER ---> MISSION TYPE 


RESULT OF CHECKING NORMAL FORMS FOR RELATION (MISSION ) 
NOTATION: Y : SATISFACTORY WN: NOT SATISFACTORY 
FD no. BCNF 3NF 


J N N 
2 N N 
3 N N 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
Extraneous attribute(s) found 
*** Before Removing Extraneous Attributes: *** 

l: MISSION NUMBER A/C_CALLSIGN ---> NUMBER _ OF AIRCRAFT 
AIRCRAFT_ TYPE MISSION _ TYPE ALERT _ STATUS 
PRIMARY _CONFIGURATION_CODE SECONDARY_CONFIGURATION CODE 
IJFF/SIF_ CODES EST TIME _AIRBORNE EST _TIME_OF RETURN 

2: A/C_CALLSIGN ---> NUMBER_OF_AIRCRAFT AIRCRAFT_ TYPE 

3: MISSION NUMBER ---> MISSION TYPE 

*** After Removing Extraneous Attributes: *** 

l: MISSION _ NUMBER A/C_CALLSIGN ---> ALERT _ STATUS 
PRIMARY _CONFIGURATION_CODE SECONDARY CONFIGURATION _CODE 
IFF/SIF_CODES EST TIME_AIRBORNE EST _TIME_OF_ RETURN 

2: A/C_CALLSIGN ---> NUMBER_OF _AIRCRAFT AIRCRAFT TYPE 

3: MISSION NUMBER ---> MISSION_ TYPE 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


CONSTRUCTION OF RELATIONS begins..... 

The relation (MISSION) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation is decomposed to : 

(MISSION_NUMBER, A/C_CALLSIGN, REQUEST NUMBER) 
(MISSION_NUMBER, A/C_CALLSIGN : ALERT _STATUS, 

PRIMARY _CONFIGURATION_CODE, SECONDARY_CONFIGURATION_CODE, 
IFF/SIF_CODES, EST_TIME_AIRBORNE, EST_TIME_OF_ RETURN) 
(A/C_CALLSIGN : NUMBER_OF_AIRCRAFT, AIRCRAFT TYPE) 
(MISSION_NUMBER : MISSION TYPE) 

Checking for LOSSLESS JOIN begins.... 


Decomposition is LOSSLESS 
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The relations are SYNTHESIZED, 
FD-PRESERVING, LOSSLESS, and MINIMAL relations 


Now, ASSIGN the relation name for new relation(s). 
New Decomposed Relations: 

(MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER) 
Enter A new name for the relation above === 
New Decomposed Relations: 

(MISSION_NUMBER, A/C_CALLSIGN : ALERT_STATUS, 
PRIMARY_CONFIGURATION_CODE, SECONDARY_CONFIGURATION_CODE, 
IFF/SIF_CODES, EST_TIME_AIRBORNE, EST_TIME_OF_RETURN) 

Enter A new name for the relation above ===> 
New Decomposed Relations: 
(A/C_CALLSIGN : NUMBER_OF_AIRCRAFT, AIRCRAFT_TYPE) 
Enter A new name for the relation above ===> 
New Decomposed Relations: 
(MISSION_NUMBER : MISSION_TYPE) 
Enter A new name for the relation above ===> 


FDs after Normalization 

1. MISSION_NUMBER A/C_CALLSIGN ---> ALERT_STATUS 
PRIMARY_CONFIGURATION_CODE SECONDARY_CONFIGURATION_CODE 
IFF/SIF_CODES EST_TIME_AIRBORNE EST_TIME_OF_RETURN 

2. A/C_CALLSIGN ---> NUMBER_OF_AIRCRAFT AIRCRAFT TYPE 

3. MISSION NUMBER ---> MISSION TYPE 


ENTERING FD FOR THE RELATION: TARGET_LOCATION 

TARGET_ LOCATION (TARGET_IDENTIFIER, MISSION _ NUMBER, A/C_CALLSIGN, 
REQUEST _NUMBER, TIME-ON-TARGET, TIME-OFF-TARGET, TARGET TYPE, 
LOCATION, TARGET_ COMMENTS) 

Candidate keys= 


1 TARGET _IDENTIFIER MISSION _NUMBER A/C_CALLSIGN REQUEST _ NUMBER 


All Fd’s entered for this relation 


I: TARGET_IDENTIFIER ---> TIME-ON-TARGET TIME-OFF-TARGET TARGET_TYPE 
LOCATION TARGET_COMMENTS 
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RESULT OF CHECKING NORMAL FORMS FOR RELATION (TARGET_LOCATION) 


NOTATION: Y : SATISFACTORY WN: NOT SATISFACTORY 
FD no. BCNF 3NF 


J N N 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


CONSTRUCTION OF RELATIONS begins..... 

The relation (TARGET_LOCATION) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation is decomposed to : 

(TARGET_IDENTIFIER, MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER) 
(TARGET_IDENTIFIER : TIME-ON-TARGET, TIME-OFF-TARGET, TARGET_TYPE, 
LOCATION, TARGET_COMMENTS) 

Checking for LOSSLESS JOIN begins... 


Decomposition is LOSSLESS 
The relations are SYNTHESIZED, 
FD-PRESERVING, LOSSLESS, and MINIMAL relations 


Now, ASSIGN the relation name for new relation(s). 
New Decomposed Relations: 
(TARGET_IDENTIFIER, MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER) 
Enter A new name for the relation above ===> 
New Decomposed Relations: 
(TARGET_IDENTIFIER : TIME-ON-TARGET, TIME-OFF-TARGET, TARGET_TYPE, 
LOCATION, TARGET_COMMENTS) 
Enter A new name for the relation above ===> 


FDs after Normalization 

1. TARGET_IDENTIFIER ---> TIME-ON-TARGET TIME-OFF-TARGET TARGET TYPE 
LOCATION TARGET COMMENTS 
ENTERING FD FOR THE RELATION: IMMEDIATE REQUESTS 


IMMEDIATE_REQUESTS (IMMEDIATE_AIR_REQUEST_NUMBER, UNIT_SUPPORTED) 
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Candidate keys= 
| IMMEDIATE_AIR_REQUEST_NUMBER 


AU Fd’s entered for thıs relatıon 
1: IMMEDIATE AIR REQUEST NUMBER ---> UNIT_SUPPORTED 


RESULT OF CHECKING NORMAL FORMS FOR RELATION 
(IMMEDIATE_REQUESTS ) 
NOTATION: Y: SATISFACTORY N: NOT SATISFACTORY 
FD no. BCNF 3NF 


J ye. 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


FDs after Normalization 

1. IMMEDIATE_AIR_REQUEST_NUMBER ---> UNIT_SUPPORTED 
ENTERING FD FOR THE RELATION: RECONNAISSANCE 
RECONNAISSANCE (REQUEST_NUMBER, PRIORITY, MISSION_START, 
MISSION_STOP, LATEST_TIME_INFO_OF_VALUE, MISSION_TYPE, 
COVERAGE TYPE) 


Candidate keys= 
1 REQUEST NUMBER 


All Fd’s entered for this relation 
1: REQUEST_NUMBER ---> PRIORITY MISSION_START MISSION_STOP 
LATEST_TIME_INFO_OF_VALUE MISSION_TYPE COVERAGE_TYPE 
RESULT OF CHECKING NORMAL FORMS FOR RELATION ( RECONNAISSANCE ) 


NOTATION: Y: SATISFACTORY WN: NOT SATISFACTORY 
FD no. BCNF 3NF 
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l X y 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


FDs after Normalization 

1. REQUEST_NUMBER ---> PRIORITY MISSION_START MISSION_STOP 
LATEST_TIME_INFO_OF_VALUE MISSION_TYPE COVERAGE_TYPE 
ENTERING FD FOR THE RELATION: RECON_TARGET 


RECON_TARGET (LOCATION, TARGET_LENGTH, TARGET_WIDTH) 


Candidate keys= 
I LOCATION 


Al Fd’s entered for thıs relatıon 


1: LOCATION ---> TARGET_LENGTH TARGET_WIDTH 


RESULT OF CHECKING NORMAL FORMS FOR RELATION (RECON_TARGET) 
NOTATION: Y : SATISFACTORY  N : NOT SATISFACTORY 
FD no. BCNF 3NF 

1 Y Y 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


FDs after Normalization 


l. LOCATION ---> TARGET_LENGTH TARGET_WIDTH 


ENTERING FD FOR THE RELATION: COMPRISES 
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COMPRISES (ATO_ START. ATO_STOP, AIR_TASKING_CODE, MISSION _ NUMBER, 
A/C_CALESIGN) 


ENTERING FD FOR THE RELATION: ASSESSES 


ASSESSES (TARGET_IDENTIFIER, LOCATION, TIME-ON-TARGET, 
TIME-OFF-TARGET) 


Candidate keys= 
1 TARGET IDENTIFIER TIME-ON-TARGET TIME-OFF-TARGET 


All Fd’s entered for this relation 
1: TARGET_IDENTIFIER ---> LOCATION 


RESULT OF CHECKING NORMAL FORMS FOR RELATION ( ASSESSES ) 
NOTATION: Y : SATISFACTORY WN: NOT SATISFACTORY 
FD no. BCNF 3NF 


J N N 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


CONSTRUCTION OF RELATIONS begins..... 

The relation (ASSESSES) was SYNTHESIZED and MINIMIZED as follows: 
Original Relation is decomposed to : 

(TARGET_IDENTIFIER, TIME-ON-TARGET, TIME-OFF-TARGET) 
(TARGET_IDENTIFIER : LOCATION) 

Checking for LOSSLESS JOIN begins.... 


Decomposition is LOSSLESS 
The relations are SYNTHESIZED, 
FD-PRESERVING, LOSSLESS, and MINIMAL relations 


Now, ASSIGN the relation name for new relation(s). 
New Decomposed Relations: 

(TARGET_IDENTIFIER, TIME-ON-TARGET, TIME-OFF-TARGET) 
Enter A new name for the relation above ===> 
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New Decomposed Relations: 
(TARGET_IDENTIFIER : LOCATION) 
Enter A new name for the relation above ===> 


FDs after Normalizatıon 
1. TARGET_IDENTIFIER ---> LOCATION 


ENTERING FD FOR THE RELATION: CONTROLS 


CONTROLS (MISSION_NUMBER, A/C_CALLSIGN, CALLSIGN) 


ENTERING FD FOR THE RELATION: REQUESTS 

REQUESTS (IMMEDIATE_AIR_REQUEST_NUMBER, MISSION_NUMBER, 
A/C_CALLSIGN) 

ENTERING FD FOR THE RELATION: INTEREST IN 

INTEREST_IN (LOCATION, REQUEST_NUMBER) 


Candidate keys= 
1] REQUEST NUMBER 


All Fd’s entered for this relation 


1: REQUEST_NUMBER ---> LOCATION 


RESULT OF CHECKING NORMAL FORMS FOR RELATION ( INTEREST_IN ) 
NOTATION: Y : SATISFACTORY WN: NOT SATISFACTORY 
FD no. BCNF 3NF 

l Y y 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 
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FDs after Normalization 
1. REQUEST_NUMBER ---> LOCATION 
ENTERING FD FOR THE RELATION: MAY DESIGNATE 


MAY_DESIGNATE (A/C_CALLSIGN, MISSION_NUMBER, POINT_NUMBER) 


ENTERING FD FOR THE RELATION: UPDATES 


UPDATES (ATO_START, ATO_STOP, AIR_TASKING_CODE, MISSION_NUMBER) 


ENTERING FD FOR THE RELATION: REFUELS 
REFUELS (MISSION_NUMBER, A/C_CALLSIGN, REQUEST_NUMBER) 


Candidate keys= 
] A/C_CALLSIGN REQUEST_NUMBER 


All Fd’s entered for this relation 


1: A/C_CALLSIGN REQUEST_NUMBER ---> MISSION NUMBER 


RESULT OF CHECKING NORMAL FORMS FOR RELATION ( REFUELS ) 
NOTATION: Y : SATISFACTORY WN: NOT SATISFACTORY 
FD no. BCNF 3NF 

1 BY Y 


Removing the EXTRANEOUS ATTRIBUTES begins...... 
No extraneous attribute found 


SEARCHING for REDUNDANT FDs begins..... 
NO redundant FD found. 


FDs after Normalization 
1. A/C_CALLSIGN REQUEST_NUMBER ---> MISSION NUMBER 
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Normalizer Functional Dependencies Summary 
ASSESSES FDs 


TARGET_IDENTIFIER 
m 
LOCATION 


CONTROLS FDs 


CALLSIGN 

---> 

CONTROL_AGENCY 
PRIMARY_FREQUENCY 
SECONDARY_FREQUENCY 


CONTROL_AGENCY 
Seen 
CONTROL_POINT 


IMMEDIATE FDs 
IMMEDIATE_AIR REQUEST NUMBER 
m 
UNIT_SUPPORTED 

INTEREST FDs 
REQUEST_NUMBER 
u: 

LOCATION 

MISSION FDs 
REQUEST_NUMBER 
ES 


LOCATION_TYPE 
LOCATION 
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MISSION_ NUMBER 
A/C_CALLSIGN 
REQUEST NUMBER 
ae 

ALTITUDE 
MISSION_COMMENT 


MSN FDs 


MISSION_NUMBER 

A/C_CALLSIGN 

> 

ALERT_STATUS 
PRIMARY_CONFIGURATION_CODE 
SECONDARY_CONFIGURATION_CODE 
IFF/SIF_CODES 


A/C_CALLSIGN 

mis 
NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE 


MISSION_NUMBER 
---> 
MISSION_TYPE 


RECEIVING FDs 


MISSION_NUMBER 
A/C_CALLSIGN 

= 
NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE 
AMOUNT_OF_FUEL 
REFUELING_TIME 


NUMBER_OF_AIRCRAFT 
AMOUNT_OF_FUEL 

= 
FUEL_REQUIREMENTS 
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RECON FDs 


REQUEST_NUMBER 

---> 

PRIORITY 

MISSION_START 
MISSION_STOP 
LATEST_TIME_INFO_OF_ VALUE 
MISSION_TYPE 
COVERAGE_TYPE 


RECONTGT FDs 


LOCATION 

---> 
TARGET_LENGTH 
TARGET_WIDTH 


REFUELS FDs 


A/C_CALLSIGN 
REQUEST_NUMBER 
=> 
MISSION_NUMBER 


TARGET FDs 


TARGET_IDENTIFIER 
> 
TIME-ON-TARGET 
TIME-OFF-TARGET 
TARGET_TYPE 
LOCATION 
TARGET_COMMENTS 
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APPENDIX G: NORMALIZED RELATIONAL SCHEMA 


AIR_TASKING_ORDER (ato start, ato stop, air tasking code :) 
ROUTE (mission number, point number : control_point_type, location, arrival_time) 
RIO_LOGS (mission_number : actual_time_of arrival, actual_time_of_retum) 


BATTLE_DAMAGE_ASSESSMENT (location, time-on-target, time-off-target : 
percent_ordanance_on_target, percent_target_destroyed, bda_comment, unit_supported) 


IMMEDIATE_REQUESTS (immediate _air_request number : unit_supported) 
RECON_TARGET (location : target_length, target_width) 

COMPRISES (ato_start, ato_stop, atr_tasking code, mission_number, alc_callsign :) 
CONTROLS (mission_number, alc_callsign, callsign :) 

REQUESTS (immediate air request number, mission number, alc callsign :) 
INTEREST_IN (request number : location) 

MAY_DESIGNATE (a/c_callsign, mission number, point number :) 

UPDATES (ato start, ato stop, air tasking code, mission number :) 

REFUELS (a/c callsign, request number : mission_number) 


COMMUNICATION_DATA (callsign : control_agency, primary_frequency, 
secondary_frequency) 


REPORT-IN_POINTS (control_agency : control_point) 


RECEIVING_AIRCRAFT (mission number, alc callsign : number_of_aircraft, aircraft_type, 
amount_of_ fuel, refueling_time) 


FUEL_REQUIREMENTS (number_of aircraft, amount of fuel : fuel_requirements) 
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REQ_LOCATION (request number : location_type, location) 
REQ_STATUS (mission number, al/c callsign, request number : altitude, mission_comment) 
MSN_STATUS (mission number, alc_callsign, request number :) 


A/C_STATUS (mission number, alc callsign : alert_status, primary_configuration_code, 
secondary_configuration_code, iff/sif_codes, est_time_airbome, est_time_of_retum) 


A/C_WEAPONS (a/c_callsign : number_of_aircraft, aircraft_type) 
MSN_TYPE (mission number : mission_type) 
TGT_MSN (rarget_ identifier, mission number, alc callsign, request number :) 


TGT_DATA (rarget_identifier ` time-on-target, time-off-target, target_type, location, 
target_comments) 


TGT-TIME (target identifier, time-on-target, time-off-target :) 
TGT-ID_LOCN (target identifier : location) 


RECON_REQUEST (request_number : priority, mission_start, mission_stop, 
latest_time_info_of value, mission_type, coverage type) 
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Normalized Relational Schema File Format 


AIR_TASKING_ORDER 3 3 
ATO_START 
ATO_STOP 
AIR_TASKING_CODE 


ROUTE 5 2 
MISSION_NUMBER 
POINT_NUMBER 
SONTROE POINT TYPE 
LOCATION 
ARRIVAL_TIME 


RIO_LOGS 3 1 
MISSION _NUMBER 
ACTUAL_TIME_OF_ARRIVAL 
ACTUAL_TIME_OF_RETURN 


BATTLE_DAMAGE_ASSESSMENT 7 3 
LOCATION 
TIME-ON-TARGET 
TIME-OFF-TARGET 
PERCENT_ORDANANCE_ON_TARGET 
PERCENT_TARGET_DESTROYED 
BDA_COMMENT 
UNIT_SUPPORTED 


IMMEDIATE_REQUESTS 2 1 
IMMEDIATE_AIR_REQUEST_NUMBER 
UNIT_SUPPORTED 


RECON_TARGET 3 1 
LOCATION 
TARGET_LENGTH 
TARGET_WIDTH 


COMPRISES 5 5 
ATO_START 
ATO_STOP 
AIR_TASKING_CODE 
MISSION_NUMBER 
A/C_CALLSIGN 


De 


C7 
C7 
LA? 


L 3 
N,2 
C3 
@ 20 
C7 


C,8 
N,4 
N,4 


C,20 
Es 


N,2 
N,2 
C20 
I 


ES 
Cy 


C,20 
Cy 
C7 


C7 
C,7 
C,43 
C,8 
GAZ 


CONTROLS 3 3 
MISSION_NUMBER 
A/C_CALLSIGN 
CALLSIGN 


REQUESTS 3 3 
IMMEDIATE_AIR_REQUEST_NUMBER 
MISSION_NUMBER 
A/C_CALLSIGN 


INTEREST_IN 2 1 
REQUEST_NUMBER 
LOCATION 


MAY_DESIGNATE 3 3 
A/C_CALLSIGN 
MISSION_NUMBER 
POINT_NUMBER 


UPDATES 4 4 
ATO_START 
ATO_STOP 
AIR_TASKING_CODE 
MISSION_NUMBER 


REFUELS 3 2 
A/C_CALLSIGN 
REQUEST_NUMBER 
MISSION_NUMBER 


COMMUNICATION_DATA 4 1 
CALLSIGN 
CONTROL_AGENCY 
PRIMARY_FREQUENCY 
SECONDARY_FREQUENCY 


REPORT-IN_POINTS 2 1 
CONTROL_AGENCY 
CONTROL_POINT 
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C8 
C12 
SH 


C,5 


CA? 


C,6 
C,20 


C12 
C,8 
N,2 


CF 
El 
C,43 
CS 


en? 
C,6 
C8 


Cle 
CA 
Cc 
CS 


CA 
C,20 


RECEIVING_AIRCRAFT 6 2 


MISSION_NUMBER C,8 
A/C CALLSIGN C12 
NUMBER_OF_AIRCRAFT N,2 
AIRCRAFT_TYPE <6 
AMOUNT_OF_FUEL N,4 
REFUELING_TIME C7 


FUEL_REQUIREMENTS 3 2 


NUMBER_OF_AIRCRAFT N,2 
AMOUNT_OF_FUEL HA 
FUEL _REQUIREMENTS N,4 

REQ LOCATION 3 1 
REQUEST_NUMBER C6 
LOCATION_TYPE C6 
LOCATION C,20 


REQ STATUS 5 3 


MISSION NUMBER es 
A/C_CALLSIGN C12 
REQUEST NUMBER ` Cp 
ALTITUDE es 
MISSION_COMMENT C72 


MSN_STATUS 3 3 


MISSION_NUMBER Cs 
A/C_CALLSIGN cua 
REQUEST_NUMBER C6 

A/C_STATUS 8 2 
MISSION_NUMBER C8 
A/C_CALLSIGN 612 
ALERT_STATUS oe 


PRIMARY_CONFIGURATION_CODE C3 
SECONDARY_CONFIGURATION_CODE C,5 
BE/SIF CODES C5 
EST_TIME_AIRBORNE N,4 
EST_TIME_OF_RETURN N,4 
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A/C_WEAPONS 3 1 
A/C_CALLSIGN 
NUMBER_OF_AIRCRAFT 
AIRCRAFT_TYPE 


MSN_TYPE 2 1 
MISSION_NUMBER 
MISSION_TYPE 


TGT_MSN 44 
TARGET_IDENTIFIER 
MISSION_NUMBER 
A/C_CALLSIGN 
REQUEST_NUMBER 


TGT_DATA 6 1 
TARGET_IDENTIFIER 
TIME-ON-TARGET 
TIME-OFF-TARGET 
TARGET_TYPE 
LOCATION 
TARGET_COMMENTS 


TGT-TIME 3 3 
TARGET_IDENTIFIER 
TIME-ON-TARGET 
TIME-OFF-TARGET 


TGT-ID_LOCN 2 1 
TARGET_IDENTIFIER 
LOCATION 


RECON_REQUEST 7 1 
REQUEST_NUMBER 
PRIORITY 
MISSION_START 
MISSION_STOP 
LATEST_TIME_INFO_OF VALUE 
MISSION_TYPE 
COVERAGE_TYPE 
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E12 
N,2 
CG 


Cs 
cS 


C,20 
Cs 
C12 
C,6 


C20 
EN 
en 
C,6 
20 
35 


C,20 
Cy 
C7 


C 20 
C20 


C,6 
Cl 
C 
Cy 
CIl 
CO 
Cy 


APPENDIX H: dBASE IV REPORTS 

Retrieving information in dBASE IV is accomplished through queries. Queries generate 
views of the database to meet the user and application requirements. Views are virtual 
databases, logical, not physical structures. Views allow: 

e data to be seen in different ways without physical duplication 

e manipulation of data without changing original database 

- database security 

- users to be shielded from changes in the physical database 

The query generated views are used by user for "on the fly" manipulation of data, or by the 
application for report and form generation. Tables are linked to one another in the DASC 
database through queries, and views, forms, and reports developed using these multiple tables. 
The following examples show the capabilities of the DASC application: 

- Report-In/Out Log view that links multiple tables 

- BDA update form for data insertion of BDA data 


- Immediate Air Support Report that lists immediate air support requests received, 
supported unit, mission assignment and BDA 


- Report-In/Out Log Report 
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REPORT-IN/OUT LOG VIEW 





unN 


|AtTuobesx | MOTA|| 


L/T Saal MATAOTY\eTduesqp\ :4| 


9 HOVAUVOS 

Lol NT-HN v HOVAUVOS 
Z LSOH9 

L ugarwa 

Z8MN9 | 8T-W/4A S YITIIN 
€ HMVH LHSIN 

Z8AW9 | 8T-¥/4 T 





TXF oL 09 SPTeTA 2ZTUPBAIO 


2SMOXY 


9000HtZ 
VOOOHOE 
COOOHOE 
LOOOJOE 
GO0O0OJOE 
£000J0€ 
TOOOHOE 


SPA1O0D9Y 


E 


BDA UPDATE FORM (empty) 


BDA UPDATE FORM 


LOCN 


TOT TET 


(ORD ON TGT 0 TGT DEST 


BDACMNT 


SUPPORTED 





BDA UPDATE FORM (complete) 


BDA UPDATE FORM 


LOCN 32SMV1234512345 
TOT 3013002 TFT 3013102| 
ORD_ON_TGT 50 TGT_DEST 50| 


BDACMNT 
2 TANKS DESTROYED 


SUPPORTED 3/1 
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Page No. 


11/25/91 


IMMEDIATE 


es. SO cs Si Ps, “E e. CO e, 
a 


Page No. 
11/25/91 


CR CRE CE CE ie ee en 
ee = ce ee dem eme 


30F0001 
30F0003 
30F0005 
30F0007 
30H0002 
30H0004 
23H0006 


IMMEDIATE AIR SUPPORT SUMMARY REPORT 


1 IMMEDIATE AIR SUPPORT SUMMARY 


-m tte ds cute CE «me Qu ee GEHEN: ANNE AN den mm, den ee ee ee ee ee CNE ee CE dan CNE ANNE MEN dt 
dee = so Á GENE GE ee ee ee ae ee ee eee eee ge 


SUPPORTED MSNNO BDA BDA COMMENT 

3/1 30F0001 50/50 2 TANKS DESTROYED 

3/1 30H0006 90/90 DESTROYED VEHICLE 

REPORT-IN/OUT LOG REPORT 

1 REPORT-IN/OUT LOG 
cs NO ACTYPE ETR ETA ATA ATR CONTROL C/S 
KILLER 1 2 F/A-18 1330 1200 1300 1345 RED DOG 
NIGHT HAWK 3 1 RF-4 1545 1430 1430 1530 BLACKLIST 
KILLER 5 2 F/A-18 1200 0 O BLACKLIST 
RAIDER 7 1 KC-130 1500 1130 1245 1530 BLACKLIST 
GHOST 2 6 CH-46 1100 0900 845 1000 RED DOG 
SCARFACE 4 2 UH-1N 1015 0845 845 1000 BLACKLIST 
SCARFACE 6 2 AH-1W 1330 1200 1300 1415 BLACKLIST 
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